Over the last couple of weeks I have been trying to formulate a law based on my experiences over the last 8 or so years writing software for companies. I think I have almost nailed it.
The Keyboard Law
(or The New Keyboard Law):The total amount of unnecessary time elapsed between a developer requesting a new keyboard, to the time when it arrives in their hands, is directly proportional to the amount of bureaucracy within the department or organization he/she works for. As a corollary, this time is inversely proportional to the amount of influence software engineering experience has within the upper management of said company.
[Warning, below I go on a long rant explaining this law, feel free to skip it and just use this law in practice and give me credit,fame and fortune in the future. Also skip to the end and add your comments too ;P]
This is loosely based on Conway’s Lawy and Parkinson’s Law of Trivialty (aka the Bikeshed Example), and while it hasn’t been proven with empirical evidence, it humorously captures a common theme in the software industry. If any University Soft Eng profs want to fund me to do the research, give me an email ;). This is an issue of micro management on how to keep software developers happy. It is just a small piece in the puzzle that I think can keep a growing company run smoothly. The second you find yourself coming up on the bad end of the Keyboard Law, it’s likely because the company is still trying to micromanage things like a purchase of a $40 keyboard.
Why I think this Law is important
The fact that it is humorous (to some people at least) is a problem on its own. Does it have to be a keyboard? Of course not, it could be a mouse, software license, monitor, chair, etc… it doesn’t really matter. What does matter is that the item must come with a reasonable justification of why or how it could improve the productivity of the developer. This doesn’t apply to a developer requesting a 42″ screen, but it does apply to one who was given a 15″ CRT and is struggling to have 4 terminal windows open on top of their IDE. Any unnecessary obstacles put in the path of a developer will cost a company money, and often more money than it would have taken to eliminate these obstacles in the first place.
A Potential Solution
First off, a developer should be managed by someone aware of this problem, and that manager should do everything in their power to minimize the negative effects. Knowing to escalate justifiable hardware requests, or having a very efficient procurement process in place is a start. A more general rule suggests that managers should always hide/minimize the amount of visibility of any bureaucracy which may provide unnecessary distractions to the development team.
The next suggestion is to create a slush fund. That’s right, I said it. Per team, per group, whatever, just have a tech manager, or operations manager (thank you Byron, the Tech Operations Manager who got me a testing netbook in less then 2 hours of requesting it) properly manage a fund specifically for dealing with this kind of stuff. If a proper, efficient process isn’t in place, a small on-the-books fund is a quick and easy solution. If a proper process is in place, make sure the managers streamline this process to make it as painless as possible.
Approving the slush fund is another story, but we aren’t talking about the $80K “entertainment” fund the sales guy gets to take clients to shows and steak dinners. I am talking $5k for an entire team, for essentials, like a proper orthopedic chair for the guy who can’t work for more than 1 hour due to back problems, or the extra monitor for the guy who is always remotely monitoring 10 different servers. Cheap stuff. Make it simple, cut out the BS and let developers do their jobs.
This is a CHEAP Fix for a Major Problem
Whether your fund is $5k or $20k, that solution is CHEAP. Developers don’t want more money. Repeat, developers don’t want more money. They want enough money, a competitive salary for instance, but not basketball player kind of money. This is not an issue of money, this is an issue of how much bureaucracy a developer can stomach in order to get his/her job done. Joel Spolsky said this 4 years ago:
‘No dysfunctional politics’. Programmers have very well-honed senses of justice. Code either works, or it doesn’t. There’s no sense in arguing whether a bug exists, since you can test the code and find out. The world of programming is very just and very strictly ordered and a heck of a lot of people go into programming in the first place because they prefer to spend their time in a just, orderly place, a strict meritocracy where you can win any debate simply by being right.
If a developer is going to pull an all nighter to finish a project that was mis-scheduled by you (the manager), then you’d better get him that 12 pack of Mountain Dew he asked for. And you’d better make sure as hell that the bill doesn’t end up in his lap at the end of the quarter. If a developer is blocking on a software license, and literally can’t work without it, the company is losing money every hour until that license is purchased and the developer is back to work. If there is actually hesitation behind buying the $500 license, think about the money being lost over the 2-3 days of deliberation.
This should also not be confused with frivolity. This approach should also not be confused with an incentive option. “If I don’t spend it this year, I’ll lose that on my budget for next year” completely misses the point.
Lastly, Software Developers Are Weird
Read, WEIRD, not SPECIAL. There is a common misconception that developers demand to be pampered or privileged. In my experience, Software Developers have strange and unconventional motivations. Giving them more money will not result in better, faster results. This has been proven true for all types of people, not just developers. Some developers like staying late in the office to play board games, or go straight home only to remote in and continue working. Sometimes, a 6-pack of Code-Red Mountain Dew will be more valuable than a $15K incentive bonus, because developers are that weird.The motivation of many great developers is to solve hard problems, and contribute, not to wrestle with politics, budgets, and red tape. Now on that, nobody likes that stuff. But continuing from saying that developers are WEIRD, they are the types to get exceptionally mad or overly frustrated about these things. If the focus and attention is shifted away from a real problem at hand, to a 3-page hardware request, the cost of that mental context switch will be astronomical. If the hardware approval finally goes through, and the CC chain goes 5 layers up in the organization to a Sr. VP approving a $100 monitor, there is a problem. By the time it goes that far up, a request for a monitor seems like another expense, and it is very unlikely that this Sr. Manager will get why it is a necessity. To a developer, explaining 2 weeks later that the request for a mouse was denied by the President of the company is like secretly inserting a printf("Segmentation Fault"); exit(0); into their source code somewhere. Its just a totally unnecessary slap to the face.
On the Corollary
I threw that in there to show an exception to the case. You can have a large company, with a lot of bureaucracy, but still have a short turn around on these types of expenses. If the structure of the department has an experienced operations manager keeping the train moving, then the developers won’t get distracted, and progress will be made. If a flexible spending budget exists for a team, it is probably because who ever requested it, or approved it, knew that these things need to be accommodated for. If every hardware request needs to pass by a VP who doesn’t understand the technical justification for a purchase, it should be realized that it is probably for the same reason they hired technical developers to implement solutions they can’t solve on their own.
Take the Test!
I’d love to hear feedback, have you ever experienced this? How big is your company? And how long did it take you to get what you really needed? How long did it take to get that keyboard with Chinese characters because you are doing translations, or a license to Windows7 because you are doing platform testing? If you don’t even know who to ask within your company… the Keyboard Law clearly defines your organization.
Ian Chan's Blog 
Awesome post. I was totally laughing while reading it! The statement about the “context switching” is so true. The loss of focus is disastrous.
On a related technical note, I’d like to tell you why your segfault prank wouldn’t fool me:
1. It’s printed “Segmentation fault”, without the capitalization of “fault”
2. The above message is printed to stderr, not stdout
3. The exit status would be 139, not 0
However, now I’ll know who to ask about mystery “crashes” =)
Nice, Mike!
One liner: raise(SIGSEGV);
Ian, great article. At our company we definitely make a conscious effort to make sure our dev team has all the creature comforts they need. As you say, it’s not that devs have a burning desire for a larger monitor or a better keyboard, it’s that the lack of a comfortable and usable environment will reduce their effectiveness – you wouldn’t expect a surgeon to work with a blunt scalpel, or a pilot to fly a plane with a stuck rudder.
You people and your crazy programming languages. Inserting artificial seg faults into people’s code is about the extent of my C.
Good analogy. A small monitor to a developer is very much like a blunt scalpel. Unfortunately most people don’t see it that way, and think developers are spoiled.
This is brilliant Ian.
The slush fund is a great idea. Although giving it that name immediately would raise red flags with the bureaucrats, the idea of a discretionary fund for an IT manager would remove so many barriers to progress.
A critical point is that the money for such a fund would be seen as a total loss for the company. Once it’s give to the manager, for all intents and purposes, the money is gone. For instance, a company couldn’t try to keep on its books whatever was purchased as an asset, for write-offs, etc. It would truly have to be money that just disappeared, otherwise the same problems start popping up again.
Monkey: Can I have $200 for a new monitor?
Manager: Sure, but get me a receipt.
Monkey: No problem
Manager: Oh, and you need to fill out this form for accounting detailing what you purchased, and a 100 work explanation why it was necessary.
Monkey: Alright, I guess I can live with that.
Manager: Oh, and since the money isn’t in my hands right now, it will be available in the month following the billing cycle when your paperwork is approved. Then my manager will get a check, who will pass it on to her secretary to record, then after 4-5 business days you will get a check in interoffice mail. Then you have to wait 5 business days for the check to clear at your bank.
Monkey: Fuck it
Mike, I swear I’ve participated in that exact dialog before… I also assume you are not referring to the same monkey from the Dilbert comic at the top. hahaha
thanks for the comment
PS: I love how you sign your posts as Alfred. That movie was on last night now that I think about it.
hah, I absolutely agree. It should be called the keyboard number of a company. Deserves an Urban Dictionary definition!
We were thinking about the KC: Keyboard Coefficient :)
You should see what its like in hospitals…
one time i wanted more ram to run CAD and FEA programs and I had to go through the IT department, even though there was multiple computers in the lab sitting around not in use without monitors. I could have fixed the problem in 5 min, yet it takes them 2 weeks just to get them ram…
Just recently I dealt with trying to get voicemail setup. omg. After talking to 5 different individuals on 3 different numbers over two days, the gentlemen said to me “your phone does not exist” despite the fact that I had called him from the phone…
“Your phone does not exist” that is just classic… Thanks for the anecdote, I want to build a collection, print out hundreds of copies of a compilation, and leave it at the doorstep of _________.
The fact that you had problems at a hospital is both not surprising, and terrifying…
On the CorollaryI threw that in there to show an exception to the case. You can have a large company, with a lot of bureaucracy, but still have a short turn around on these types of expenses. If the structure of the department has an experienced operations manager keeping the train moving, then the developers won’t get distracted, and progress will be made. If a flexible spending budget exists for a team, it is probably because who ever requested it, or approved it, knew that these things need to be accommodated for. If every hardware request needs to pass by a VP who doesn’t understand the technical justification for a purchase, it should be realized that it is probably for the same reason they hired technical developers to implement solutions they can’t solve on their own.
+1