It's strange how at times various sources all talk about the same thing..
- I've been (re-)reading a load of books lately (which is my excuse for not doing any blogging ) and all of them talk about programming quality (Facts & fallacies about software engineering, the mythical man month,...).
- I downloaded a few episodes of Elegant Code podcast, of which episode 7 is of special interest.
Is code art or science ? - The Alt.net mailing list contains the thread When is it overkill
- some discussions at work and so on..
The following reply by Greg Youn sparked off the this post - as it's the answer I often get from my fellow consultants.
I used to believe heavily in the writing of great software ... since then I have grown up and been knocked off my soap box. Now I understand that there is only one kind of great software and that is the one that best solves the issues of the stakeholders, the quality of the code generally has little to do with it.
I call this the 'as long as it works' reply...
I *get* this reply, even if it goes against a number of my personal beliefs.
The thing of note in Greg's reply is his mention of the stakeholders of the project/application.
Question is, who are these stakeholders:
Business
 | I'm guessing everyone knows 'the iron triangle', which is how most managers perceive software creation: a balance between cost, time and features. As a result, your acceptance criteria by which your customer will accept your product are directly based on the features of your application. This (in theory) should lead to adequate software, aka software that does what it's supposed to with no or little bugs. |
Technical
The technical department is the second stakeholder, which may or may not exist (depending on your client's size). If a technical departement exists, it often/mostly gives you some rules about the development or forces a framework on you, but only in extreme cases will it actually do code reviews.
To top it off, acceptance criteria often leave the technical department out of the loop..
Maintenance.
aka, the hidden stakeholder. If we can trust the numbers mentionned in facts & fallacies, 60 % of software costs are done in maintenance, and 60% of maintenance is enhancing of existing applications. So, roughly 40% of all software projects are adding features to an existing application, aka brownfield projects.
In my personal experience, projects that were produced with a 'good enough' approach tend be nightmares when you need to extend or correct them..
In the end I agree with greg's definition.. as long as all the stakeholders are sufficiently taken into account, software should be good.
