It would be nice, and often can be done, a delivery of on time and working software. The axiom of on time, working, or cost comes into play here. I just want to discuss (and rant) a little about on time and working software.
Sometimes during a project there comes a decision point were a leadership team has to decide between on time delivery and working software. I’m not talking about cutting some features and getting it working to deliver on time. I’m talking about just simply delivering whatever is done at a particular point so that it is on time or continuing and delaying the release.
Sequential and Parallel Tasking
I mentioned recently the problems associated with adding developers to a software project. One of the main things that comes up as a conflict with additional developers is the sequential nature of software development scheduling. Some tasks you cannot work in parallel, and must have clear starting points based on ending points of other tasks. The simple of this I’ll describe by using a few examples below.
Example Scenario: The Beginning, The Creation
When a team, product manager, marketing director, or entrepreneur get an idea and set out to create that idea it is a sequential or serial action task. Small parts of the idea can be broken off for elaboration but generally it takes x amount of time, indivisible into smaller time segments.
When a time segment is introduced that is sequentially ordered it is because of several reasons. The number one reason for sequential ordering is that the workload can be broken down no further, the solution being developed is already for the smallest segment of breakdown that is reasonable.
Example Scenario: The Busy Work, The Day In and Day Out
When a team is working on a large project and the parts of the project are broken down one can task parallel items. One example of this is any SOA (Service Oriented Architecture) Project. With SOA the parts of the overall application usually make up some grand application of enterprise massiveness. In these cases multiple parallel tasks are a necessity and additional developers can be added with a large benefit. These tasks then of course need broken down into smaller sequential tasks for each individual.
Summary
In several of the companies I have worked for and a couple startups that I am consulting on at this time there is a recurring theme I see over and over that almost predicts various levels of failure or induced burnout in developers. The arbitrarily set “completion dates” for a project. In multiple projects that I’ve seen, a completion set is made by either executive or middle management with no realistic goal, baseline, function list, or even clear scope idea of what needs to get built.
Per many management processes such as Six Sigma, Lean, Scrum and others one of the core fundamental concepts is for pushing off the decision making on important things like that until the most information is available. The last thing one should do is promise delivery when development hasn’t even started.
The best thing to do is to work out timelines and scheduled deliveries when baseline times can be created. If there are none of the previously mentioned baseline or time data points, the legitimacy of a project being completed at a set time is 0 (zero, zilch, nada). Nothing can change this except additional data points.
Last word – forget the damned dates, make sure the software works and release often. I guarantee better return on the investment will be had!
