A bit of history: Waterfall
When I was a student I was taught that the life cycle of software is very simple, is just a straight process defined by the following consecutive activities: Analysis, Design, Coding, Testing and Deployment which by that time made a lot of sense to me, oh! life was easy….
Then I start working as a programmer, and I saw that life cycle applied on practice. I saw the project manager doing an amazing planning effort, the architects and designers doing thousands of UML diagrams and the programmers trying to implement those designs as well as possible to hand over to the testers… but, the plan was always inaccurate, the design was 40% wrong, the implementation took forever and at the end there was just one day for testing.
Conclusion: The process (Waterfall) is prone to a lot of failures, misses planning and doesn’t generate the expected output.
Not all the waterfall projects were claimed to be a failure, some of them were claimed successful, but amazingly even for those projects it was normal to find failures like that they needed extra time/money, didn’t deliver 100% of the functionality, some parts of the software were not as the customer expected…
Conclusion: Even when claimed as successful most waterfall processes contain quite a lot of defects at the end of their life cycle.
Can you imagine acceptable in some other industry that what it fails is the process to create a product, not the product itself?
Conclusion: Let’s think it all over again.
What is software development? A traditional answer would be something like: “Software development is the process where we get some requirements and we translate them into software”, then everything is about getting upfront the correct requirements, right? Well, after 10 years of experience developing software, I can only say that that’s wrong, let’s see why:
1.- It is impossible to get all the requirements upfront
Anyone who has been in any medium/large size project knows that there are always big mistakes/leaks in the requirements gathering phase: sometimes you don’t get all the requirements, sometimes they are wrong, sometimes there are missing requirements for some parts of the application, sometimes they just change… The requirements of an application will only be clear when the application is completed.
2.- Customer only have a vision and few ideas, they don’t know about requirements
Is well known that in order to gather the requirements we have to meet with the stakeholders, interview them and extract the requirements, how do we do that? By asking lots of questions and refining their answers into requirements, well, the truth is, customers and stakeholders don’t know what the requirements are, they just know about the big picture and requirements are about details.
3.- Requirements are goals not iputs
The biggest misunderstood of all is to think that the requirements are inputs to the project, that’s false, requirements are goals, are the small pieces that need to be discovered that make all the objectives and visions come true.
4.- Requirements can only be validated when they are imlemented
Requirements are just the representation in plain English of some software behaviour, so a requirement is likely to be wrong until we don’t validate its implementation.
5.- Requirements are linked with each other by a very complex, very difficult to predict net of dependencies.
Even after validating a requirement through its implementation, it’s possible that a change in some other requirements causes this requirement to change. You can only be 100% sure of the validity of a requirement, when all the other requirements have been validated.
What is good software development?
As opposite to the traditional approach where requirements are the base of software development, I propose an approach where the base is some ideas/visions and we help the customer to translate them into software by discovering simultaneously the requirements and their implementation.
Good software development is the process where we help the customer to figure out what software they need by finding all the requirements while we build them.