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 you are determined to have your software development project fail miserably.
Back in September, I promised I was going to post a law per day until I ran out of things to say. That lasted, well, zero days :-). For various reasons I felt it prudent to delay posting these for a couple of months.
The laws I am going to post are in no particular order in terms their impact. I am not sure how many of these laws there will be, and I am not even sure that they will not end up being self-contradictory.
(hey, I am doing this like a typical software project!)
I think the laws will fall into a few main categories:
- Project planning and tracking
- Process, methodology, blah, blah, blah
- Working with management
- Working with marketing
- Quality, testing, etc.
- Technology and tools
Something to keep in mind here is that I am a big fan of process in software development. Not of big, heavy processes, but of some process. If you are going to go from A to B, you have to follow some process to get there. There is value in having some level of predictability and repeatability in that path. You may vary the path with the circumstances, but you should at least know what path you are improvising around.
Also, I do not believe that there are any rules which you can follow which will guarantee perfection in you software development efforts (at least not if you are building anything interesting). All of the rules, and process, and other magic spells can do is to improve your probability of success, and allow you to see when you are heading down the path of failure, allowing you to make some intelligent decisions along the way.
On the other hands, the are a few rules you can follow which can almost guarantee that your project will fail. Combine a few of them together, and you can make your failure truly spectacular. Stay tuned…