The Code Whisperer

Unachievable schedules have blighted the industry since the dawn of software development. Here’s some reasons why this happens:

• Schedule set before requirements agreed and/or understood
• Pressure from customers
• Inexperienced staff, in any combination of the industry, application or development tool
• Use of leading edge technology
• Poor estimation
• Estimate overridden by senior management
• Features added but the plan not amended
• Low estimates produced as a challenge or as an incentive to work harder
• Poor measurement of progress
• Fixed deadline, such as a sporting event, new tax year or introduction of regulations

Schedule set before requirements agreed and/or understood - This is particularly prevalent in software houses, where the primary goal is to get a customer to sign up for work. The software house doesn’t want to spend money before they get the sale, so only sufficient scoping to sell the software or enhancement is carried out. In an ideal world the software house would give a rough estimate, which would become more accurate as the analysis and technical design progressed. The problem is that customer want to know exactly when the software is going to be ready before they sign and the sales team can use the time taken to develop the software as a bargaining point, however, as we all know, this is a bad idea. So what do we do? Ideally invest time in having senior analysts and developers work out an estimate for the work, add some contingency and present that as a non-negotiable estimate that will be refined during the analysis and technical design phase. Make sure, however, that at the end of technical design the remainder of the schedule is as accurate as you can make it. Now this approach will lose sales, but for sales gained it is much more likely that the software will be delivered on time. Quite frankly a software house that has a reputation for delivering on time and in budget is going to attract the work most people want to do.

Pressure from customers - reducing the time leads to cut corners, software with bugs and demoralised development teams. The customer that suggests removing a month from a development schedule wouldn’t dream of suggesting to a surgeon that their knee operation must be an hour shorter, so why do the same with software development. My advice is it this occurs before the sale is made and you are confident with your rough estimate, walk away. Easy to say, harder to do, but once you’ve reduced your time estimate to the potential customer with out good reason, for example increasing development resource where it makes a difference or reducing functionality, your estimates lose credibility.

Inexperienced staff, in any combination of the industry, application or development tool - one of the biggest assets existing developers have is in the industry and applications your team produces. A high turnover of staff, or resourcing using a pool of developers means that a proportion of the developers may not be as productive to begin with as others. Obviously this depends on whether an existing application is being modified and how detailed the technical design is, but it can be an overlooked factor in scheduling.

Use of leading edge technology - using the latest and greatest is a developer’s dream, but can cause all sorts of delays due to bugs in the new technology or its implementation with the rest of your environment. For example I spent ages trying to get Visual Basic 5, RDO and Oracle stored procedures to work efficiently. It turned out due to an incompatibility between RDO and Oracle, with both companies blaming the other for the inefficiency. There is something to be said for using an established technology, mostly because most problems will have been discovered, overcome or not, but details available on the Internet.

Poor estimation - developers frequently underestimate the amount of time to do things and project managers must be aware of this and adjust accordingly. Overruns from one project need to be analysed and used when estimating the next. It’s important to learn from project plans, whether they are correct or not but in order to do this it’s vital that the time taken to complete tasks is accurately captured, without the developer feeling they have failed if the overrun is due to poor estimation.

Estimate overridden by senior management - senior management can reduce estimates for a variety of reasons and mostly it’s a bad thing. The only way to resolve this is the respect and relationship senior management has for the project manager producing the estimate.

Features added but the plan not amended - there seems to be a stigma about changing a plan once it’s underway. Some added features will have little or no impact on the schedule provided they are introduced at the right time, but most additional work will have some impact. Not to replan is madness.

Low estimates produced as a challenge or as an incentive to work harder - some developers, particularly those that enjoy heroics, will purposely estimate work on the low side as a challenge. It’s important that the project manager spots these and adjusts accordingly. One way to avoid this is to have two or more developers estimate task independently. It’s vital that this is carried out in isolation, particularly if one developer has better knowledge of the system than the other, because if this is done publicly there will be a tendency for the second estimate to be very close to the first. Using a tight schedule to increase efficiency in a team is just wrong and won’t work. If you need more efficiency from a team look at the other postings in this series, you should find help there.

Poor measurement of progress - it’s vital to collect information as development progresses - time taken and progress made. These are not the same. 5 hours spent on a task estimated to take 10 hours does not necessarily mean it’s half way through. I know this seems obvious, but it’s incredible how many plans are controlled in this manner. It’s also important to break tasks down as small as possible so that slippage is easily apparent. I prefer to have tasks lasting no more than two days and preferably one day as any slippage is known after two days, whereas if it was lumped with other tasks that combined took up two weeks, potentially slippage wouldn’t be discovered until late into the second week.

Fixed deadline, such as a sporting event, new tax year or introduction of regulations - if this sort of project is started late there is no simple solution. In order to deliver on time it may be necessary to increase resource, but only if it will make a difference (see Adding People to a Late Project), or reduce functionality.