The trouble of finished software

I think that there is a very important question, and that is the question of what constitutes a finished software.

Well, that might seem easy. It should just work as specified.

Having a good specification is by all means helping to remedy this problem. Specification might be defined somewhere in a document up-front or agreed upon during the agile process. One trouble with relying only on specification is that natural language is not very precise, especailly compared to the programming language, therefore leaving room for interpretation. There is always room to write better documentation, but it will not make the problem dissapear. One of the possible paths is to look for formal specification methods, but the problem there is that not all stakeholders can interpret the formal pseudo-code or diagrams.

Assuming we have a decent specification, how could we tell if our software conforms this specification? Testing comes to mind, with all its variety of approaches, but also code inspection and analysis. Unit testing also has a mission to check if software conforms the specification, assuming that tests represent the specification accuratelly. Even with all these activities in place, we cannot have 100% conformance, because testing and unit testing always rely on some representative samples of behaviour. Maybe with good formal definitions we can have high conformance which is possible to check, but I haven’t used these tools myself.

Going back to our problem, it seems as the level of finished can be defined as combination of level of completeness of specifications, and level of conformance to the specification:

finished(software) = completeness(specification) * conformance(software, specification)

It is very important that all stakeholders in software projects understand that “finished” is a vague category, a matter of discussion. The term itself sounds as the final state, which is very different from reality. Maybe the term should be replaced with another term, such as “acceptable”, because it implies a level of acceptance. And level of acceptance is matter of agreement, which must be explicit between all parties.

To conclude, concept of finished software is too idealistic, and should be replaced with acceptable software.

This entry was posted in Development process. Bookmark the permalink.

2 Responses to The trouble of finished software

  1. I agree. Software needs to pass “acceptance” tests. Nothing is really final and everything evolves. I’d say that software comes closer to “acceptable” for each non-essential feature that you remove from it. I’d like to see an anti-software-bloat movement rise up. I don’t care if storage and RAM is dirt-cheap. I like tools that do one thing really well. Talking paperclips and animated dogs are not essential features.

  2. PM Hut says:

    Hi Nenad,

    I think that’s the whole point of having the the definition of done in agile.

    As for your last part, I agree with you, stakeholders have all to understand defines the finish line of the project. But quite often this is easier said than done.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>