Reader comments to "How I write software"

Editor's note: Here are two of the longer comments we received from readers responding to Jack Crenshaw's column "How I write software." Many more readers responded, but their responses are no longer available online on our new web site. At this time, I'm not sure when and if the older comments will be restored and brought over to the new web site.
--S.Rambo
Managing editorEmbedded Systems Design magazine

Letter #1
I always enjoy reading Jack Crenshaw's column because we share the perspective that comes from extensive experience developing embedded software. I've been at it for 35 years, starting out like he did by feeding paper tape through a Model 33 ASR. We both migrated into the field from a science-mathematics-engineering background. I worked in applied physics for the first decade of my career. Computer science and computer engineering did not exist as majors when we graduated.

Despite our similar backgrounds, I respectfully disagree with most of his assertions in "How I write software" (June 2010, p.9). He "jump[s] right into the code", starting by writing the null program. From there on, it's just a matter of filling in the details, right? Well, I contend that there are a few fallacies in his approach.

His article contains numerous instances of the first person singular pronoun, "I." Nowhere do I see the first person plural "we." Evidently he always writes his programs alone. I almost never do. I can count on one hand the number of projects that I've developed alone, with a few fingers left over. Perhaps as a solitary developer, he can start out with "void main(void){}" but what if the three or five or 10 team members all start there? The project would quickly descend into chaos. What's more, I've seldom had the pleasure of starting a fresh project at all. The vast majority of my assignments over the years could be classified as maintenance--adding features, extending functionality, fixing errors, etc. Some of the programs that I've maintained probably started out with void main(void){}. Those [programs] are the hardest ones to fix; some simply must be discarded because every modification attempted has unexpected and unwanted side-effects.

I agree that rigid rules in the development process are undesirable and should be unnecessary, but a completely undisciplined approach is even worse. On the one hand, Jack Crenshaw states that "Law #43 says design it before you build it." A little farther on, he says that "using my approach, the requirements evolve with the code." Which is it--design first or build first?

Every engineering project can be divided into two phases--design and implementation. In every other engineering field, engineers do the designing and someone else does the implementation. Civil engineers don't pour concrete or drive rivets; mechanical engineers don't operate machine tools; chemical engineers don't plumb refineries; electrical engineers don't lay out circuit boards. But software engineers do their own implementation--it's called programming. That's both a blessing and a curse. It's a blessing because we don't have to wait days or weeks or months for our creations to be realized; we are able to see our designs operating almost immediately. It's a curse because there's a great temptation to short-change the design phase and go immediately to the implementation (jump right into the code). Generally when a person starts programming, he or she stops thinking. Good design gives way to trial and error. I'm prone to this myself, because programming is more fun than designing. Strong self-discipline is required to resist the temptation. I am convinced that I achieve the best results in my projects by postponing programming as long as possible.

Jack and I have both seen a lot of programming fads come and go, sort of like clothing fashions. The latest are spiral development, agile and extreme programming. They, too, will fade in time because they cannot replace fundamentally sound engineering design. Like Jack, I also test my program modules as I develop them, but I don't delude myself into thinking that testing substitutes for design. Which Mars probe was it that crashed because two modules assumed different force units? I suspect both modules were thoroughly tested; apparently the high-level design, if it existed, wasn't reviewed. I have often heard a poorly written program defended because "it works." Does that mean that the expected inputs produce the expected output? What about the unexpected inputs? A back-of-the-envelope calculation quickly leads one to conclude that it's impossible to test all conceivable inputs. For even a simple module, the combinations are astronomical. I used to display a placard in my cubicle (when I had a cubicle) with a quote from Edsger Dijkstra that says "Testing proves the presence, not absence, of bugs."

About seven years ago two colleagues and I embarked on the development of a new product for our employer. The three of us agreed at the outset that we would write and review a design document for each principal module before beginning coding. This was not an elaborate formal waterfall process, but it did cause us to think through the designs before investing a lot of effort in programming. The result was by far the most successful product that the company has ever developed. Sales have exceeded forecasts by an order of magnitude, and at this writing it remains the company's flagship product. Furthermore, the software architecture that we jointly developed has been used as the foundation for no fewer than five other significant products. Many code modules have been reused with little or no modification. Others have been easily extended to meet the added requirements of later products. We worked together so closely as a team that it was difficult to tell where one person's work ended and another's began. We would never have achieved that success if we had "started with code."

As I wrote once before to the editor, the magazine originally entitled Embedded Systems Programming is now named Embedded Systems Design. When it is finally renamed Embedded Systems Engineering, it will have arrived.