Carson Baker

I want to high­light this par­tic­u­lar link, “Top Ten of Pro­gram­ming Advice NOT to follow” [sic]. Except for #10 (throw excep­tions), every one of these sug­ges­tions flies in the face of what pro­gram­mers are tra­di­tion­ally taught. The gen­eral com­plaint that the author makes (sug­ges­tion #1) is that design is over­rated. Start coding instead! I com­pletely agree, with only a few pro­vi­sions. Take time to think about what’s going on, but don’t waste valu­able time cre­at­ing formalisms.

Unless you’re work­ing for NASA, you prob­a­bly don’t have to prove your invari­ants—so stop pre­tend­ing. If you under­stand the prob­lem you’re approach­ing, and you’re com­pe­tent enough, you’ll quickly figure out a rea­son­able way to get there. Even if you make mis­takes along the way, who wants to bet it’s easier to cor­rect them after the fact, when every­thing is set out plain and clear than it is to try to nail the solu­tion the first time around. Think about the trade­off you make every­time you draw a UML dia­gram. Is your care­ful plan­ning really saving devel­op­ment time? No, you’re mas­sag­ing your­self into delu­sion—your model isn’t robust; you’ve ignored the imple­men­ta­tion details; and now you have to manage another com­po­nent of the system.

Let’s think about the evo­lu­tion of soft­ware design over the past decade and try to draw out a few points. In the begin­ning there was assem­bly, of which the func­tion call pat­tern was a design issue. C made it obso­lete—you had to use it. Then the the­o­rists spent their time lec­tur­ing on the OO par­a­digm, writ­ing books, and gen­er­ally coerc­ing the masses into its adop­tion. C++ obso­leted that. Since then, fur­ther refine­ments in the way we pro­gram have tran­spired, giving rise to Java, C#, and agile tech­niques. So at least for the moment, the issue of design has been resolved. Given the hard­ware we cur­rently use it seems unlikely that there will be any new par­a­digm shifts. Oh no. What are the authors, the the­o­rists, and the man­agers to do?

Here’s a chal­lenge: find all the soft­ware design books of the past few years and look up the author’s biogra­phies. How many still reg­u­larly pro­gram? It should be sur­pris­ing, except when you real­ize that there’s a lot more money in con­sult­ing than in actual pro­gram­ming. I’d say most of the “top ten” advice you get when you read about soft­ware engi­neer­ing should be taken about as seri­ously as your horoscope.

Yet although they’re obnox­ious, I don’t see the des­ig­narati as the reason people fall into the pit. To me soft­ware devel­op­ment is an art. It requires prac­tice and learn­ing by exam­ple, also by doing. And it’s a sub­jec­tive thing; what works for you may not work for some­one else. The impor­tant thing is think a little about what makes sense and then get to work. You can’t pre­emp­tively design your way to a solu­tion. It’s a pre­ma­ture opti­miza­tion of the very worst temptation.