Bob on Development

January 6, 2007

Writing Polite Code

Filed under: Communication,Techniques — Bob Grommes @ 7:09 pm

I ran across a generally excellent essay by Michael Feathers on what he calls Offensive Coding. The essence of his argument is that if you find yourself frequently writing defensive code (he uses checking for null as an example), the root cause may be that the code you’re working on is called by offensive code. In other words, code that forces you to write defensively.

This resonates with me. Some of my clients have been with me for as long as a decade, so I maintain a heck of a lot of code. Some of it is mine, and some of it is not. I’ve never minded maintenance and refactoring as much as most of my colleagues appear to, but one thing I don’t like about maintaining code is the inordinate amount of time I spend either coding defensively, or doing forensic work to document what the heck is going on so that I don’t have to code defensively.

The opposite of offensive code might be called polite code. And it strikes me that one of the features of polite code is that it’s as self-evident as possible and accurately documented. Good code is self-evident as to the “how” of what it’s doing, and documentation in the form of comments and external documents provides the “why”.

I just spent a couple of hours reverse-engineering some code that handles an automatic product version upgrade because I did not want to risk hosing a production system without being sure about how some items in an application config file were set. I shouldn’t have had to do that, but every reference I could find to these configuration items were vaguely worded and not written with the question in mind, “what will be the concerns of the user reading this”?

That happens a lot … documentation frequently answers questions a user would never ask or give a fig about. It states the obvious, or beats the irrelevant to death, but it never addresses a likely real-world question. To be concrete: the meaning of “InstallMemberRole=true” was I’m sure quite obvious to the original author at the time he was in the throes of creating it. And it seems most likely that this item, in the context of the section of a portal framework configuration most likely means that during the installation process, the member role feature will be installed.

What isn’t ever stated is whether this applies to version upgrades, and if so, whether it will blow away an existing user base. God bless Google, I found some people discussing it who said that it would in fact blow away the existing user base. But, those people may or may not know what they are talking about, and besides, isn’t it odd to default this setting on and thus put people’s user bases at risk? And maybe it involves upgrades to functionality that I’d want to weigh the benefits of.

Well, no matter … with over 1500 impatient active users at stake I can’t afford to guess, so I plowed into the code and tracked down the called T-SQL scripts and made damned sure. This is a defensive action I should not have had to undertake.

As I have said elsewhere, English is a programming language too, and this is another example of why that’s so.

December 27, 2006

Is Development a Science or an Art?

Filed under: Communication,Managment,Projects — Bob Grommes @ 2:10 pm

Let me say right up front that we’re not going to clear up the age-old argument between developers and bean-counters in this space. It’s been tried, over and over, since the beginning of the computer age.

Instead, I’ll just say that I think that, in the same way light has properties of both waves and particles, software development is both art and science. Indeed, in my view it’s a little more art than science. And I think that, just as there are very few true athiests in the world, there are very few people who would truly maintain that there is no art to development, and even fewer who would maintain there is no science to it.

Now that we have that out of the way I want to address the folly of going to the extreme of removing the craftsmanship from development and treating it as science.

Leaving aside my deeply-held suspicion that science isn’t going to save us anyway … that the image of dispassionate, relentlessly objective Men in White Lab Coats is a myth … let’s just say that there are powerful forces that want to make development into something that can be quantified, bottled, automated, commoditized, offshored, and in general made Predictable. These forces are well understood.

Historically every New Thing starts out as an arcane craft and is made one at a time, painstakingly. At some point, when its worth is proven, that product becomes standardized and commoditized so that it can be mass-produced, mass-affordable and more reliable (or at least Good Enough).

It is perfectly understandable that the world of business would hope that this paradigm could be applied to development. Especially since, tantalizingly, it appears that in some ways, it can be applied to development. For example, we can codify “best practices” and “naming standards”, and perform “static analysis”. We can use team development environments that enforce Corporate Standards — which can be either good or Stoopid, but let’s just assume they’re all good.

Even while conceding those points, though, there is a significant part of any non-trivial software development project that requires, not cold hard science, but passionate craftsmanship. And this is not just isolated to, say, the analysis phase of a project. It’s a thread that runs all through every part of the development life cycle.

Software develpment requires precious intellectual resources to be done right. Every day on a project, dozens of decisions must be made as to how to spend and apply those scarce resources. One must not only navigate the technical decisions, but the often conflicting and irrational political, regulatory, and marketing considerations which the project must effectively engage in order to be useful to anyone. And all of these factors are in constant and often chaotic change.

It’s tempting for non-developers and new developers to focus on the relatively easy stuff … the bare, obvious technical considerations, and assume that standard reductionist scientific thinking will eventually bring about predictable, reproducible results. But the truth is that organic, integrative, holistic thinking is needed, too. And that is the work of the mature craftsman.

This is happening in other fields of scientific endeavor as well, but it’s just easier to overlook. Historically, science’s hope was that by providing increasingly detailed understanding of natural processes we would come to fully understand them. But the fatal mistake was assuming that the universe is not infinitely intericate and complex, and that the same rules apply to the tiny picture (the sub-atomic level) as to the big picture (the cosmolocial level) and to everyday life at human scale. Science is increasingly running into trouble here. We have not found a hard limit to the size of the universe in either direction; we keep discovering annoying new dimensions we didn’t know existed; we keep encountering new rules that put previously accepted scientific fact to the lie.

It’s no different in the world of software development. You’ll never remove the need for the true craftsman. It takes someone who can deal with both the slippery, subjective, gut-level and human factors; it’s not just the technicians twiddling dials. And even the technicians should use Common Sense ™, which is not something that grows on trees.

The core skill of the software developer is correctly identifying and solving problems. Everything else is just execution. When software development projects are so often misbegotten and misdirected, we should not redouble our efforts to execute better. We should redouble our efforts to correctly understand the problem and the best points of leverage for addressing the problem.

Alas, accurate perception and accurate judgments about what to do with those perceptions, are not terribly amenable to Standard Processes. Knowledge and wisdom are two different things.

December 18, 2006

English: The “other” programming language

Filed under: Communication — Bob Grommes @ 9:00 pm

I just finished reading J.Timothy King’s provocative essay, “Does Bad Writing Reflect Poor Programming Skills?”. King’s answer is an unqualified “yes”, and I have to mostly agree with him.

The difference, of course, between communicating with human beings and communicating with a computer is that computers have infinite patience. You can probably be a boring, unimaginitive writer and still have good programming skills (although arguably, if you lack imagination you may fail to think outside the box enough to come up with the best solutions consistently). What you definitely cannot be, though, is an unclear writer.

King’s point is well-taken, too, that a program must be comprehensible to other developers and maintainers, and to your future self months or years from now — not just to the computer.

The scary thing is that an astounding number of programmers (I won’t dignify them with the term “developer”) not only can’t write, they can’t even read effectively.

In my experience if you assign a task to a good developer, they will annoy you with pertinent questions until they understand every detail of what you’re asking them to do. If you assign a task to a lousy developer they will read the first two sentences and might manage to misinterpret even that much.

For example, I recently gave instructions to a programmer working on a web form that included home and work phone number fields. I stated, “In both the home and work phone numbers, the last seven digits may not be the same.” In other words, 480-111-1111 is not a valid phone number, nor is 480-777-7777.

Instead of what I asked for, the code the programmer wrote checked that the last seven digits of the home and work phone numbers were different from each other. So 480-111-1111 would be okay for a home phone so long as a different number was used for the work phone. Not even close to what I was looking for.

Predictably, other aspects of the code were “off”. One of the objectives of the code rewrite was to establish redundant validation on both client and server so that people with JavaScript disabled — and spam-bots — could not enter invalid data. The classic ASP code being worked on submitted the form to a separate ASP page for processing. Rather than combine the two or make sure the server-side validation was on the processing page, the programmer did the server-side validation on the form ASP and then submitted the validated data to the processing page via an in-the-open querystring, so that things were still readily hackable by simply submitting a bogus form directly to the processing page.

Coincidence? I think not. And no, I didn’t hire this guy. Thankfully he took 30 hours to do 8 hours worth of work, which got the attention of the non-technical hiring manager, and this particular programmer was un-hired in short order — proving once again that money talks. It saved me a half hour of patient explanation of exactly how this fellow was dropping the ball.

If you’re not comfortable quickly and accurately reading and clearly writing in plain old English, tackle English as your next “programming language”. The job you save may be your own.

Create a free website or blog at WordPress.com.