It’s 2015 and we still have no flying cars. (Dear Doc Brown, we still need roads. Love, Andy) On a similar note, we’ve suffered through another year of software breaches and empty promises to fix the issues behind them. Brian Kelley (Blog | @kbriankelley) was right, We Don’t Care About Data and IT Security.
Part of the issue is testing. Do you test for security?
Estimation
I am often asked, “Andy, how long will it take to test this solution?” My response is, “About as long as it takes to develop the solution.” Project managers love me. Well, not so much. It’s not their fault, the blame lies with unrealistic expectations and the response is usually along the lines of, “Will adding people to this project shorten the development cycle?” to which I respond, “I have nine women, can I get a baby in one month?”
So what happens? The testing cycle is compressed from weeks or months into a few days or a week. And we wonder why there are security leaks? and why the software doesn’t perform?
Results
Please join me on this asymptote for a little hyperbole…
If we flew airplanes like we manage software projects the plane would take off, fly to the destination at altitude, and nose-dive into the runway. From 30,000 feet to 0 feet in a straight line; straight down. The results of such a trip match what we see in software development.
When people talk to me about software projects like Healthcare.gov, they act as though this is a fluke. It isn’t a fluke; this is how software is developed in the mid-20-teens. Stakeholders say they want quality, but what they mean when they say “quality” is that they want to hit a deadline. Please do not misunderstand me: deadlines are important for a host of legitimate and good and right reasons, but they are no good for software security and solutions testing.
Developers vs. Estimation
Stakeholders (rightly) question the estimates of developers because most developers stink at estimation. One of two things must be true, though:
- Developers are liars or idiots or pig-heads who will not or cannot or refuse to produce useful estimates; or
- The work is inestimable.
The answer is 2.
Solutions
This is not an easy problem to solve. “Why is that, Andy?” I’m glad you asked. The definition of stupid is doing the same thing over and over again and expecting different results. Here are some things to change if you want different (or even better) outcomes to your software development projects:
- Realistic expectations. If software is inestimable, how much time should be spent trying to produce an estimate? Let’s see… doing the math here… carrying the one… I get precisely 0 hours. Stakeholders know what they want and – usually – when they want it. Start there, add what developers know, and walk away from this 15-minute meeting with the expectation that work will begin and you will meet again tomorrow to see how much work has been accomplished.
- Authority. The developers have none, the stakeholders have it all. Scrum places responsibility for development in the hands of developers and equips them with the necessary authority to make decisions about the features that are implemented in each sprint. If developers lack the authority to remove features from the sprint, you are not practicing Scrum. Period.
- Communication. Scrum supports daily communications between developers and stakeholders. Stakeholders are not allowed to speak during the 15-minute stand-up meetings. If stakeholders are talking, you are not practicing Scrum. If stakeholders are not in attendance, you are not practicing Scrum. (Do you sense a pattern here?)
- Time. Testing and development take time. The biggest mistake in software estimation is planning for nothing to go wrong. Plan for everything to fail (at least once) and then succeed.
- Money. If you believe software development and testing are expensive, you should see the price tag for a data breach. Enough said.
Conclusion
Evidence-based management provides vital feedback. Learn to apply EBS in your organization; it’s the most effective way to improve software estimation.
Comments