Poor programming has long been attributed to poor productivity of developers. This again is a function of low skill level, poor motivation or simply below standard coding practices. The truth of the matter is, the root cause of poor developer productivity is poor software estimation.
Here are the five ways in which poor software estimation can lead to bad programming:
1. Inaccurate Estimates Affect Quality
Accuracy of estimation is a much talked about subject in the software development process. Uncertainty, risk and unknown variables strongly play around software estimation, making it highly dynamic in nature.
Many formulas and algorithms have been evolved as an answer to curb and control risk associated with software estimation, but with little success. Most of the time the estimate forecast ends up not being accurate, which causes severe repercussions related to the final product.
If the scope definition was improper, a scope creep is definite at later stages. Due to delivery schedule commitments the developers come under pressure to deliver ‘on time’ and the overall effect is on the quality of the final software system. So although productivity of developers gets the blame, the truth is that work done under pressure would surely have poor quality.
2. An Uncertain Environment Adds Contextual Elements to be Estimated
Even the best of intentions, highest level of calculations and a good track record of past project, does not guarantee a similar experience for your next software project. This happens because your operational environment both micro and macro does not remain constant. The contextual elements of your software project keeps changing with new variables to estimate.
Dynamism exists with great certainty and as pointed out by Donald Rumsfeld the problem of ‘known unknowns and unknown unknowns’ make accurate planning difficult. There are things for which you simply cannot plan or anticipate with certainty.
For example, the next day you might witness new issues cropping up; such as new developers joining the team(different learning curve), revised organization/client goals, a sudden change in market scenarios introducing demand for a new feature. I am sure all these changes never figure in the mind of estimators during the primary estimation process. How do you plan for an uncertain future and estimate extra effort for it? You simply cannot!
Most organizations expect and accept the unpredictability of estimates in software development process. But many don’t and productivity of developers forms the softest target to get the blame of budget overrun and delivery delay.
Solution: Realization and Acceptance of uncertainty as an inherent aspect of software development process allows the team to prevent from optimistic bias rule estimation. It is always safe to assign some time for ‘unknown unknowns’ which anyways are certain!
3. Testing Effort –Did You Factor Time for Testing in Your Estimate?
Testing is a very important activity which contributes towards product quality. Organizations might conveniently seek to ignore testing effort as they aim to strike balance between the sales and delivery cycle to maintain cash flows.
Testing effort is not accounted for in the final effort estimates. While overoptimistic estimates may win the project in the short term, it may actually turn detrimental in the long run as they are playing with the quality aspect of the software. The final system would have bugs and errors. So while the actual problem was in allocating effort for testing, productivity would get the blame poor quality.
Solution: A test management system is essential for ensuring quality of the software system. Properly adding the testing effort and explaining it the scope document will make things clear and allow you to have the time to create a high quality system.
At the development front, the developers need to use a system of estimation which allows justification of every hour which is added to effort estimate –be it development or testing.
4. Lack of Making Improvements from Past Estimation Experience
Organizations estimate effort for a software project at the beginning, which is later compared to actual effort taken at the end of the project. A deviation between the estimated and actual shows estimation inefficiency.
In a practical scenario very few organizations and development communities analyze the deviation related to actual and effort estimation. Causes could be operational inefficiency, process inefficiency, or inappropriate team allocation.
Manual study of individual projects and deviations related to actual and estimated effort hours is too costly and not feasible. Manual estimates lack in detail and various areas which get covered only during the implementation phase affecting the developers capability to complete the project in time and within cost.
Lack of an automated system which is able to capture contextual elements of software estimation along with well defined effort drivers prevents both correct estimation and negates scope of learning from inappropriate effort estimation.
Solution: Instead of blaming poor team productivity, organizations should institute a system where developers can easily assess issues and causes which led to poor effort estimation and make way for learning and improvements in estimation.
5. Absence of Mechanism for Benchmarking Development Productivity
Skill level of the team is an important variable in the entire estimation process. During estimation however, the expert estimator does not factor in a baseline or benchmarked productivity matrix for effort calculation. Effort is estimated as if the expert estimator is supposed to do the coding himself. Producing generalized numbers which resonate with high expert proficiency/productivity and applying the same to developers is a not a rational decision. The estimates would go wrong and developer productivity would be blamed.
Simply blaming productivity for poor programming does not negate the absence of a clearly defined productivity matrix for software development. Most organizations lack a mechanism of defining productivity baseline of developers. In its absence, it is difficult to follow, measure and assess productivity mismatch with each project completion.
A productivity assessment would allow examining issues at various stages of development which affected productivity, analyze scope of improvement and relate true causes of inaccurate programming practice.
Solution: Managing productivity of developers requires setting organizational productivity benchmarks for various implementations and ensures that estimators consider the baseline while estimating. Manually this becomes too difficult.
An automated system which enables a benchmarking system related to setting baseline metrics for developer productivity needs to be instituted in the organization. This would help in creating realistic estimates that truly reflect developer productivity. Any variation in actual and estimated effort would then help analyze the existence of true productivity and operational issues and chart strategies to deal with them.
Enough of blame on developer productivity for every project which has failed or been pulled back midway. Estimation lies at the root of bad programming practice and we need a system to handle it.
QuickFPA, an automated software estimation tool enables you to deal with bad programming practices in real sense by establishing benchmarks for productivity standards and estimating on defined matrices. It enables a granular estimation where every project activity and effort hours are intelligently justified.
With QuickFPA, your scope document would be a fairly justified explanation of your budget for delivering a Quality Software. It’s high time that as players in the software industry we should seek to establish ‘quality as the ultimate goal’, instead of focusing on underestimation to win the project bid in short run and blame poor productivity as the reason of failure in the long run!!