Attila Buturla

Creating working software is relatively easy. Creating high quality software that exceeds expectations is hard. In my last two blog postings I've discussed the challenges of managing software projects, in particular when dealing with external customers. On the one hand a customer wants to know how long a project will take and how long it will cost. On the other hand we simply don't have accurate ways to measure how long a project will take, due to all of the variables involved. One can try traditional project management techniques to pretend to know how long a project will take, or one can use agile techniques which don't lend themselves to determining the cost all up front. I fully understand why a customer wants to know how much something will cost. When I go to my mechanic with a problem, they provide me with an estimate of what they think is wrong and how much it will cost. Of course once they pop the hood and start working they often find unexpected issues, and the

In part I of my blog posting on estimating agile projects, I discussed how a prior employer attempted to use waterfall techniques to ensure that customer's projects were delivered on time and on budget. In the end the waterfall project management techniques added a lot of overheard with negligible benefits. Of course this was just one company's experience. Having said that, I worked for several more companies that also used waterfall techniques and those techniques rarely resulted in software projects that were on time and on budget. On the contrary they added a lot of overheard and did little if anything to improve the quality of the software. Within the last few years agile practices, including Scrum, have become common place in software development. I first used Scrum about seven years ago, and immediately saw the benefits. The focus was on producing usable software, while detailed specs and projects plans were no longer needed. At the time I worked for a company that was

Over the course of fifteen years as a software developer, I've worked for nine different companies. They ranged in size from under fifty employees, to over a few thousand. They spanned many different industries including financial, medical, retail/e-commerce, and custom software development.  While they each differed in many ways, one thing was constant; as software developers we were required to provide estimates for how long it would take to develop our software. In particular, three of the companies that I worked for were software consulting shops. By that I mean we wrote custom software for our customers. In these cases getting software estimates wrong didn't just make the team look bad; they could be the difference between the company making or losing money on a project. If too many projects were underestimated, it could potentially result in financial hardship for the company and ultimately even layoffs. The first software consultancy that I worked for was back in 19