Sunday, April 21, 2024

Human Generated Story

 In this world of everythingGPT, we are now surrounded by artificially created nonsense.

Inspired by the one-word-story game, Human Generated Story is a multi-player web game that allows you to invite your (human) friends and create some fun nonsense without the help of any machines or their learning.

Have fun!

Friday, January 14, 2022

Headcount Fallacy

(DISCLAIMER:  I’m not presenting original ideas here. I apologize for any missing attributions and welcome any/all suggestions to appropriately attribute any ideas)

Do you want to maximize productivity of your software development team? Most people* would say yes, if they have anything to do with a software development team. If you say yes, another question to ask is “can I increase my team productivity more by 1) adding more programmers or 2) by improving training, tools, facilities, work environment, face-to-face time, development lifecycle process, and other intrinsic motivators.” If your organization’s instinct is to respond with 1) then you are falling into the headcount fallacy. 

To give an example, say you have a distributed team of 8 people working on a software product. If their mean salary is $100,000, that means you have a budget of $800,000. Assume your company spends $10,000 per team member per year on equipment, training, travel for team building and offsite work sessions, etc. Say your business wants to increase its rate of feature development by, say, 20%.

Plan A would be to hire four more team members for a team size of 12.  This would increase the annual budget by $440,000. With a team of 12, and no other changes, a 20% increase might be possible†, especially if your company hasn’t succumbed to the headcount fallacy to get where it is today.

Plan B would be to hire 2 more team members for a team size of 10, but use the extra $220,000 each year (increasing budget to $32,000/mo each)  for better equipment, training, vacations, some face-to-face offsite meetings, etc. Unless your team already has the best equipment, training, and productivity enhancing accouterments already, this would almost certainly have a bigger than 20% increase impact on productivity. Certainly it would improve team performance more than adding 4 more folks who are immediately stretched to the limit.

The above scenario is oversimplified to make a point (we are ignoring full costs of employing people, for example), but if you consider costs of turnover in your staff, the scale tips much more towards Plan B, since you are lowering your risk of losing hard-to-replace staff (both their skills and tribal knowledge).

For ideas on how to spend extra dollars on team productivity instead of headcount for a development team, I suggest reading Dan Pink’s book Drive. It shows the motivators for information workers. For other teams the ways to increase productivity and reduce turnover will probably be different but the same headcount fallacy applies to all kinds of work.

* I have had discussions with managers in the past where they did not agree with this goal. Instead, their focus was on individual productivity.  If that’s the case for you, then skip the rest of this post :)



Thursday, February 25, 2016

Slicing the Pie

Just stumbled across this fascinating video--A number of years ago I tried to set up a similar scheme, but Mike Moyer seems to have done a great job of adding risk weighting factors and anticipating all the possible scenarios.

Play more sports!

PlayCity matches you with nearby people who want to play the same sports you do. We are in beta and we are looking for test users for our iOS app. You will also require an active Facebook account. 
Please email with your Apple ID if you'd like to be included in our beta group. Thanks!

Friday, November 6, 2015

Stop Writing Bugs

Recently I watched Douglas Crockford's New Developer's Conference 2014 talk. (Is there a more up-to-date version out there?)

It reminded me of something: most of the great programmers I've admired over the years were the ones that seemed obsessed with not writing bugs. Crockford's talk starts with the motivation for JSLint (I run all my JS code through this great tool)... help the world avoid bugs.

It seems like such a basic tenet but many programmers and even more managers/owners don't seem to value this hygiene factor enough.

Many of the other principles I strive to work by are inextricably linked to bug avoidance:

* DRY:  Needless duplication and redundancy increases the chances of writing a bug
* KIS: Simple, elegant designs lead to fewer (or at least easier to find) bugs
* Only build what you need: If you focus on minimum viable products, minimum viable implementations, etc., you are much less likely to add bugs.
* Test oriented/driven development: As a last resort, most of us also need a thorough test harness and coverage to help us avoid writing bugs.

(On a side note, I was inspired by Crockford's talk to try writing some JS without using "this" -- I updated the page to avoid "this" and use the object creation technique Crockford described).

Wednesday, November 4, 2015

Affordable and improved alternative to deadmanswitch and pingdom

Now in public beta: (Watch Dog Timer) -- a new utility to monitor your systems!

Thursday, March 27, 2014

Tile Puzzle

I just put together a quick HTML5/Canvas example page at  Its purpose is to demonstrate the Canvas and some basic javascript usage including prototypical inheritance.  There are probably a lot of these out there but I tried to keep this one relatively simple and clean.  I'll probably keep tweaking it over the next little while.