Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto G

April 13th, 2009 at 8:34 pm

What is good software development?

with 7 comments

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.

The requirements

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.

7 Responses to 'What is good software development?'

Subscribe to comments with RSS or TrackBack to 'What is good software development?'.

  1. Very good article, absolutely agree with you!

    Gu S.

    14 Apr 09 at 5:15 pm

  2. Thanks for your feedback!!! And congratulations this is my first article and you are the first one to write a comment!!! I´ve I ever make it to 1.000.000 visits I’ll buy you a ham. Promise!!!!

    Alberto G

    14 Apr 09 at 8:13 pm

  3. I totally agree with you. What methodology do you use, how do you make your estimation (budget and time)? we all know that there’s two other constraints time and money!
    I’m not a fun of the waterfall model, but gathering the maximum input from the customer and from the beginning is a good thing.

    brainfault

    14 Apr 09 at 8:57 pm

  4. Thanks for the feedback!

    We are using quite a set of new an cool methodologies/processes, we have a huge kanban board, If you have never used one, go for it, it’s the best tool for making your project transparent and involve the developers, our activites are embedded in a Scrum process, we work with User Stories and we have the daily Scrum, retrospective, etc… We use the engineering practices from XP, Continuous integration, Pair programming (not always) and we are going to try TDD.

    For planning we play planning poker which is a great tool for agreeing on a plan, and we keep control of our schedule with burndown charts.

    It is true that we don’t have a plan before hand for the whole project, but I don’t think it’s possible to get a reliable one from Waterfall, we just have estimates and we make sure the customer understand that they will be revised.

    In the other hand, this set of principles, processes, make us very productive, the software we deliver is high quality and most of the times we get the result the customer was expecting.

    About gathering the maximum input from the customer, completely agree, It’s just how this input is gather which I disagree from a traditional perspective… I believe in continuous deployment and doing demos of releasable software every two weeks having involved the customer as some else from the team, that’s the way you make sure you get the right inputs. Unfortunately that’s not always possible.

    Let me as well advance you that my next post I think It’s going to be really interesting to you as it talks about inputs, outputs and actions, I hope it will be ready this week so stay tuned.

    Once again, thanks for your feedback!!!

    Alberto G

    14 Apr 09 at 9:34 pm

  5. […] to give different names to all the artifacts that somehow affect the software we have to deliver, Requirements, bugs, risks, constraints…  Are just the same, they all are inputs to the project, and they […]

  6. […] the attitude “I’m right, You’re not”, both of you are wrong. In the software development industry I’ve seen very few times situations where someone olds […]

  7. […] development is a continuous discovery process, in order to keep up to date with good code that matches the new/changing requirements is essential […]

Leave a Reply