Chapter7.Coding

Chapter 7. Coding

Sooner or later, it all comes down to "the code." As much as we would like to eliminate this pesky step, you just can't build software without writing code. Even if you think you are going to put together an application using preassembled parts, you still have to write the code to glue it all together, to pass results from one module to another.

This is both a blessing and a curse. Great code allows us to have robust systemsthe kind that don't breakas well as high-performance systemsthose that respond quickly to our demands on them. Writing great code allows us to field superior products that give us a competitive edge in the marketplace. But what about all that positively awful code that is foisted onto the general public? Anyone who thinks that "it's just code" should consider the difference between the writing for USA Today and The Economist. Both are written in approximately the same language, but the differences in level, quality, and style are obvious. To say that "it's just English" misses the point entirely.

Or, as we say in the trade, "You can write garbage in any language." This poses a problem for the software development manager. Most managers did write code at one point in their careers, and they were probably pretty good at it; that's why they were promoted in many cases. But it's likely that they used some language other than the one their team is using on the current project. This causes what you might call a first-level disconnect: Although the software development manager understands general programming problems and issues, he may not be crystal clear on why the current language du jour is offering new and ever more interesting challenges.

This problem pales in comparison to the problem the software development manager has with his manager who, in many cases, has never written a line of code. Explaining to him that the project is being held up by a coding bug is like telling him that his car has to go into the shop because its frammis is broken. In fact, it's worse, because the car mechanic can probably tell him how long it is going to take to fix or replace the frammis; we, unfortunately, can offer no such prognostic. When your software frammis is broken, it could be a long time.

I must admit that I don't have a solution to this second problem, other than to suggest you explain the truth of the situation as clearly as you can. On the other hand, I do have some advice relative to the first problem of the software development manager and a "new" language. My solution is simple: The software development manager should attempt to gain familiarity with the new language by trying it out.