the 12 test
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
With a software company, the first priority of management needs to be creating that abstraction for the programmers.
If a programmer somewhere is worrying about a broken chair, or waiting on hold with Dell to order a new computer, the abstraction has sprung a leak.
programmer is most productive with
a quiet private office, a great computer
unlimited beverages
an ambient temperature between 68 and 72 degrees (F)
no glare on the screen
a chair that's so comfortable you don't feel it
an administrator that brings them their mail and orders manuals and books
a system administrator who makes the Internet as available as oxygen
a tester to find the bugs they just can't see
a graphic designer to make their screens beautiful
a team of marketing people to make the masses want their products
a team of sales people to make sure the masses can get these products
some patient tech support saints who help customers get the product working and help the programmers understand what problems are generating the tech support calls
and about a dozen other support and administrative functions which, in a typical company, add up to about 80% of the payroll
It is not a coincidence that the Roman army had a ratio of four servants for every soldier. This was not decadence. Modern armies probably run 7:1.
(Here's something Pradeep Singh taught me today: if only 20% of your staff is programmers, and you can save 50% on salary by outsourcing programmers to India, well, how much of a competitive advantage are you really going to get out of that 10% savings?)
Internal software only has to work in one situation on one company's computers. This makes it a lot easier to develop.
You can make lots of assumptions about the environment under which it will run.
You can require a particular version of Internet Explorer, or Microsoft Office, or Windows. If you need a graph, let Excel build it for you; everybody in our department has Excel. (But try that with a shrinkwrap package and you eliminate half of your potential customers.)
Here usability is a lower priority, because a limited number of people need to use the software, and they don't have any choice in the matter, and they will just have to deal with it.
Speed of development is more important. Because the value of the development effort is spread over only one company, the amount of development resources that can be justified is significantly less.
Microsoft can afford to spend $500,000,000 developing an operating system that's only worth about $80 to the average person. But when Detroit Edison develops an energy trading platform, that investment must make sense for a single company. To get a reasonable ROI you can't spend as much as you would on shrinkwrap. So sadly lots of internal software sucks pretty badly.