Have We Finished Yet?
by Suzanne Robertson
In his keynote talk on dependable software at the 2005 Requirements engineering conference, Daniel Jackson’s urged us to “move away from infatuation with completeness”. This started me wondering – how often does anyone ever finish anything? In our everyday lives we say we have finished cleaning the bathroom, cooking the dinner, watering the garden, ironing the shirt, cleaning our teeth and a myriad of other things. But we don’t really mean that we have finished. Instead we mean that we do not have any more time to devote to that task and we have done the best that we can within that constraint. We accept the fact that we have limited time and that few of life’s daily tasks are finished to one hundred per cent perfection. Why should building software systems be any different?
A common complaint of software developers is that they don’t have enough time to finish a project. People in other professions for example engineers, architects, doctors, composers have the same problem but they have learnt to treat this as a normal constraint of their profession. They accept that:
- there will always be more to do than fits into the time available
- dynamics of the world mean that there will be changes that necessitate negotiation and replanning
- they need to be able to communicate their plans to their clients.
This perspective is about how software developers can use these principles to free themselves from “infatuation with completeness”.
| Attachment | Size |
|---|---|
| Have We Finished Yet.pdf | 183.88 KB |
Mis-conceptions of Agile methods
I think you are illustrating one of the key mis-conceptions of people who do not fully understand Agile methods, and probably one of the key reasons that business people and clients are hesitant to accept working with Agile proponents. No client will ever be prepared, nor should they be, to pay for LESS than what was promised. Because you are working in an Agile method will never imply you can deliver less than what you promised and expect to get paid in full. What Agile does imply is that you may get DIFFERENT functionality at the end of the project. So if you contract to deliver 50 business events for $50,000 you will deliver 50 business events BUT they may not be the same 50 that are identified up front AND it is the CLIENT who decides during the project which 50 he wants and in what order. ALSO if you are being truly Agile the CLIENT can cancel the project after you have only delivered 25 business events and pay you half the amount because he has already got the functionality that he REALLY needs from the system. If more developers would negotiate on this basis then more clients may be prepared to work in Agile ways.