I’m not too keen on having every detail defined before coding because the reality is that taking that sort of design approach often results in a great deal of wasted time when business needs change. I have also finally come to understand that this encourages a type of coding approach that I find distastefully inefficient: embedding every bit of functionality within as few objects as possible. In fact, this is an incredibly wasteful approach as when the same functionality is later needed elsewhere the code must be added to the other object.
That said, some project planning is key to the success of a project. One of my teams has a large project with a short turnaround requirement. I’ve broken down the work into palatable portions, but without adequate resources it will still be quite a challenge to complete all the pieces in time.
It is now my pet project, and while at first I was honestly plain scared that we could not possibly make the target, I have a new optimism and now I am seeing the potential to introduce some great improvements while we are making our modifications. It is all very exciting, and I have been reviewing some articles on Lean Software Development in preparation for a kickoff on Monday afternoon.
The midrange world is not yet accustomed to this sort of approach. Most developers are sadly caught in the 1980’s bloat evident in our applications system: several programs approaching 8,000 executable lines of code. Spaghetti, anyone? It will be an interesting challenge to redirect the approach without causing the developers to melt down with the sort of resistance born of fear. Change is difficult for most people, and I can’t deny that I am just as vulnerable to the doubt that often churns up during a transition period.