Barry Talks! : Common Sense for Uncommon Times

Sunday, September 26, 2004

Barry's Rules of Software Development

1. Great software is built by small teams. If you're building a great BIG software product use lots of small teams. The team leaders should be able to carry on a civilized conversation with one another; conversely, they should not be trying to torpedo each others' careers behind their backs.
2. Great software projects always, always have one person who gets the big picture. He/she codes. Repeat: he/she codes. This person is called the architect.
3. Software "architects" that don't code are not software architects. Sorry.
4. If you check in code that breaks the build, shame on you. If you didn't bother to test it before you checked it in, you should be reassigned to writing dot-matrix printer drivers for CP/M for the rest of your natural life.
If on the other hand your checkin broke the build because it conflicted with another checkin, get out of your office and make some new friends among your coworkers. And talk to the architect and get the big picture. If you're really conscientious maybe one day you might be like him/her.
5. In any given source file there should be more comments (as measured by number of ASCII characters, if nothing else) than code. The comments should reflect the fact that the coder knows what he/she is doing and why this code was, in fact, necessary.
Your comments should be comprehensible and grammatically correct. One day you will die, or be transferred to another project, or leave the company, and someone else will take over your code. Think about that.
6. Any coder that puts profanity in his/her code should be forced to write BIOS keyboard interrupt service routines for the rest of his/her natural life, preferably for an eight-bit microprocessor on an S-100 bus.
7. Test/QA is not there to find your bugs. (Read that twice, please.) You are there to find and fix your bugs. (Read that ten times.) Test/QA is responsible for telling manager(s) and customer(s) if your code is any good, and if it's ready to ship.
8. XML does not solve all your problems. Neither does model-driven design, or UML. You still have to write good code. Sorry.
9. Great software architecture requires thought in advance. Sorry.
10. Any coder that doesn't get the importance of user interface design up front should be forced to write IBM System/360 Job Control Language for the rest of his/her natural life.
Any coder working on a client-side app (including web-based apps) that codes without a UI design up front ought to be forced to write programs for OS/2 1.1 for the rest of his/her natural life.
11. Every coder must spend at least one day per year listening to a customer complaining bitterly about his/her product.
12. Julie's Corollary: there is a difference between "programmers" and "engineers." You know who you are.
13. Coders with Big Egos usually have Big Problems with their code.
How can you tell a Coder with Big Ego? Easy. They often a) close their office doors and refuse to talk to anyone who is "unworthy," including marketing, QA, product managers, and their own managers; b) yell derisively at QA, who have the unmitigated gall to claim their code may have bugs; c) tell everyone that "no customer would ever do that," when in fact every customer "does that"; d) usually quit either immediately before or immediately after ship, so as not to be accountable.
14. Good coders are not afraid of the words "value proposition." (Converse: good software marketers are not afraid of the words "object model.")

Comment (8) #