Fred’s Laws – How not to write software

This begins a series of posts on Fred’s Laws – basically a set of anti-rules on how not to develop software.

Over the past twenty-odd years, I have seen a lot of software projects crash and burn. Many have been doomed from the start, while many others died slow, painful deaths after hopeful beginnings. Some have finished, and the systems are in production, without ever having realized that the project was a failure. Others should have failed, but managed to struggle through due to the heroic efforts of one or more dedicated (and usually really smart) people.

I have also seen more than a few “failed” projects that were technical successes. We built really cool software. We were on time, on budget, and had good quality. They failed in some other aspect – usually they were business failures for one reason or another.

The environments in which these projects have died have been varied as well. Some tried to make it with no process at all. Some had lots and lots and lots (and lots and lots) of process. I have not seen a great deal of correlation between process and success (well, except that the process I pick for my projects is always successful 😉 ).

When I look back on these catastrophic projects, usually I can see where things went wrong. In fact, most of the time I could see where they were going wrong while it was happening, like watching a car crash in slow motion, but was frequently powerless to avoid the impact. More often than not (in fact, I would be willing to say always), the root cause was something completely avoidable (from a technical or project perspective). Never was it because we chose Windows over Linux (or vice versa), nor because of the programming language we chose, nor because what we set out to do was technically impossible.

As I have written Fred’s Laws (well, written them in my head, none of them are actually written yet!) it occurs to me that they all seem to be straight from the department of the bloody obvious. No rocket science here. If they are this obvious, why even write them down. Well, the reason is that, despite how really obvious all of this is, I watch projects not do them all the time. Most of the time, in fact.

So, stay tuned. I am going to try to post one law per day (or so) until I run out of ideas.

BTW, as a little footnote, I have been involved in a few successful projects along the way. It just always seems to be the ones that failed (and failed spectacularly) that stick out in my memory.


The Next Big Language – WHY?

I have been doing some work lately teaching myself some of the basics of Ruby, Python and a couple of other languages. As I was working with these languages, I was suddenly hit with a question – why? Over the course of my career, I have programmed in a lot of languages (somewhere around 20 that I have actually used to do useful work, I think). I am sure many of you can say the same thing. And do you know what? They all suck in one way or another! I have seen language’s popularity come and go. I have seen arguments in person, in newsgroups, and all over the web which bordered on religious fanaticism. Even as I write this, a good discussion continues in response to The Next Big Language.

Again, I ask myself “why?”

Looking back over projects in which I have participated, led, observed, or otherwise been involved, I cannot think of one where the success of failure (or degree of success – failure is not usually absolute) of the project was due to the limitations of the programming language. Nor has the programming language been the determining factor in the cost of the project, or the quality or the maintainability of the code.

There are so many factors which are accepted to have much greater impact on the course of a project than the choice of language/technology – requirements, architecture, realistic planning and tracking, and proper resourcing to name a few – that I find the whole debate around programming languages to be somewhat meaningless in the real world (actually, I find it more annoying than meaningless).

This is not to say that I do not believe we should always be innovating and inventing new ways of doing things (including programming languages). It does mean, however, that it is highly unlikely that any of these language advancements (or The Next Big Language, whatever it is) will make a significant difference in software development in either a corporate IT or commercial product development world – at least not any time soon.