Software that “more than works”

Posted by on Jan 15, 2015 in interview | No Comments
Software that “more than works”

Now that is an interesting notion.

Having working software is not enough. We need to have well crafted software.

This is one of the many interesting points Uncle Bob focused on his interview in the software engineering radio podcast.

You should really listen to it (and subscribe to the podcast).

Here is a transcript of a section that I found particularly interesting (at around 16 minute mark of the podcast), while commenting on the first line of the software craftsmanship manifesto:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

  1. Not only working software, but also well-crafted software


Yeah, now this is a bit of cleverness by the authors here. They took the four statements on the manifesto of agile software development and then they essentially moved to the left and added another column.
So the agile manifesto says we value working software as opposed to something I can’t remember [Yeah, probably documents]
And this says well we value working software, but it also has to be well crafted. And the notion of well crafted is that it more than works.
Software that works is fine, but software that works and can’t be maintained or can’t and understood is a frightening thing to have on a system, and unfortunately most of the systems out there are in an unfortunate state of disrepair, and this disrepair is hidden from the users.
The symptom is that Managers will ask for new features or bug repairs, and the estimates for those new features and bug repairs begin to stretch.
They get longer and longer as time goes on, as software developers feel so unsure in their code base that they start stretching and stretching and stretching the estimates.
I have worked on systems where estimates started at something reasonable like a week, but two years later there was no estimate shorter than three months.
That is a common symptom in software industry today.
The reason it happens is the code base falls into such horrible disrepair that the software developers themselves don’t trust any of their actions within it, so they become incredibly careful and pad all of their estimates because they simply don’t know what’s gonna happen when they change a line of code.
The notion of being well crafted is that we know what is going to happen when we change a line of code. We understand what the repercussions of every change is . We can look at a module and understand what it does and understand what the couplings are. We have the tests around it so that we know, at the push of a button, that any change we make hasn’t broken anything else, and the software is in general good.
For some reason that idea is foreign to most of the software industry out there. The focus has been so much on schedule, that the software development community has all but abandoned structure, and this is ironic, because when you abandon structure your schedules go out almost instantly. The only way to keep your schedules under control is to keep your quality very high.
So, the first line of that manifesto has a tremendous amount of implications. [laughs]

Leave a Reply