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.

Advertisements
About

I have been working in the world of technology for 25-odd years. I am an entrepreneur and consultant, focused on software solutions, social networking, and innovation processes. Currently, I am a Principal Consultant with T4G Limited, specializing in Portal Technologies (including SharePoint), software/systems development, service oriented architectures, and many other things which I will probably not remember until I need to use them. Prior to that, I was VP of Technology at Whitehill Technologies, Inc., where I spent almost 9 years helping to grow the company from a start-up to one of the most successful private software companies in Canada. Prior to that I worked on internet conferencing using early VoIP, and on large military communications projects. Before even that, I worked in satellite control, and remote sensing. Going way back to university, my focus was on theoretical physics and astrophysics. Currently my interests revolve around most aspects of software development, from technologies to management, and in the area of defining sustainable, repeatable processes for innovation within technology organizations. I also have a particular interest in Tablet PC technologies – I have been using one for several years, and I love it. On the personal side, I still have a strong interest in all aspects of science, especially physical sciences, as well as philosophy and comparative religion. In addition, I am into music, playing guitar (badly, I am sorry to say), and reading almost anything I can lay my hands on. I am also a member of the IEEE/IEEE Computer Society, and of the Association for Computing Machinery.

Tagged with: , , , , , , , , , , , , , ,
Posted in My Menu, Satire, Software Development
3 comments on “Fred’s Laws – How not to write software
  1. sandrar says:

    Hi! I was surfing and found your blog post… nice! I love your blog. 🙂 Cheers! Sandra. R.

  2. […] Laws (again) Some time back (late September) I promised a series of posts on what I term “Fred’s Laws”, a set of rules you can follow if […]

  3. hobbylobby says:

    Bring it on!

    🙂

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Obligatory Disclaimer
Please keep in mind that any opinions, points-of-view, comments, or other content which I post to this site are mine and mine alone. They in no way reflect the views of my employer, my country, my dog, my cat, or anyone else you can think of. To paraphrase Monty Python, "That is the theory that I have and which is mine, and what it is, too."

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 623 other followers

%d bloggers like this: