There is, at least here in Australia, a default approach to software development processes and related work products that has emerged by osmosis over the last ten years. Lots of people have experience with software projects and consequently believe they have some useful knowledge. The result is that a default approach that resembles a inadequate facsimile of a waterfall project is now assumed to be normal:

• There will be some requirements. They will be in a document titled “Requirements version 0.1″. This document won’t be properly reviewed by the customer and probably won’t be read by anyone in the project team except for the “business analyst”.
• A document with the title “Design version 1.0″ with a few listless class diagrams and maybe a few related UML diagrams will be written. This document will be painstakingly produced by the lead nerd or architect and will cause enormous division amongst the nerds. This document won’t be read by anyone after the 56th line of code is written.
• Coding will start at a random time but will be well underway before the documents titled “Requirements version 0.1″ and “Design version 1.0″ are ‘finished’.
• Some testers will be brought into the project about a week before coding is scheduled to be completed.
• Some documentation will be produced by a contract technical writer that accurately reflects the document titled “Requirements version 0.1″. I don’t need to say that there is a fairly large gap between the emerging code and the documentation.

I could go on.

The problem appears to be that in the absence of useful (usable?) process models and experienced and competent people to drive the use of the models this default “waterfallish” model has filled the vacuum. Is it better than not having one? I don’t know.

I’d be interested in your thoughts on this subject. Do you see something similar in your neck of the woods? If something similar does exist do you think its better than nothing?

Dare Obasanjo has a new post about something he calls false goals. He describes them as software design goals that have become irrelevant and now are negatively impacting upon a project. Go read his post for more.

I have seen the same thing happen, very frequently, in the user requirements sphere. A marginally useful business feature is added to the list of requirements. Happens all the time, especially when people are imagining the rosy new world that will spring into existence once a team of crack nerds comes to build a shiny new application for them.

Anyway, the feature, when implemented causes significant development and design drama due to its complexity. More insidiously, in a fixed price scenario (government tender anyone?), the feature, since itisn’t really needed doesn’t get attention from customers for specification and turns into a project management nightmare. “I’m afraid I can’t sign off on the contract until all features are implemented. Probity issues. What if I get audited? Anyway, are you trying to rip us off?” Can you tell that I might have been here? Once or twice?

That feels better now.

P.S. Dare is the creator of RSS Bandit my news aggregator of choice. Try it if you are looking for a good Windows aggregator.

The most valuable business lesson that a toddler can teach her parents (apart from work part-time if you can) is to start doing everything the way you intend to keep going. If the first time you go to a particular shop you cave in to a mini-tantrum or extravagant begging and buy her a present or a chocolate or an ice cream, etc. Then whenever that same shop is approached a maxi-tantrum or super-extravagant begging will occur. Similarly, if you let your daughter sit on the stool near the kitchen bench while you make dinner, then you had better be prepared for that to continue. The pain of undoing a moment’s weakness can be almost unbearable.

What’s the business hook? Glad you asked. If you hire someone then be very careful to have them do things the way you want them to continue to do them. Don’t be lazy or try to avoid conflict and decide to fix the problem “…in a few weeks, the next time he nukes someone else’s code during a check-in”. Two things will happen. The new hire will decide that you don’t care about quality (if he/she is aware of the mistake/sloppiness) or the new hire will feel unfairly stupid when (if?) you eventually provide feedback. The other problem is that all other staff will be paying attention to the new hire (as they always do) and will probably notice that you apparently no longer care about quality.

The same goes if you get a promotion, or a transfer or a new job where you are a (petit-)boss. In this case it is absolutely vital that you start true and stay true. There are lots of people watching and they are looking for little signs so they can discover what you really care about not just what you say you care about.

Recent posts

Nerdherding for Beginners is written by Michael Harmer, released under the Creative Commons Attribution-Noncommercial 2.5 Australia licence powered by WordPress and designed by XiAP Design Studio.