Many times over the years we have encountered an attitude towards code cleanliness that is summed up in the assertion that as systems grow in size, code quality will necessarily degrade. Often the argument is backed by references to ‘programming in the large’ as opposed to ‘programming in the small’. We have consistently found these assertions to be unfounded and this article is an attempt to explain why.
I was driven to write this article after reading Kirk Knoernschild’s blog about Rotting Design and felt I needed to say something.
This article continues my series on Software Quality. My thesis is that we judge quality using the same inbuilt sense of aesthetics as we would a work of art or an everyday object, albeit at quite a high level of abstraction.
This is another way of looking at how Test Driven Development (TDD) helps us build better software. [...]
As a retrospective facilitator I frequently see different parts of a team presenting different perceptions of the same event. In fact, this underlies a great many of the problems seen in teams.
“In the long run, men hit only what they aim at. Therefore, though they should fail immediately, they had better aim at something high.” – Henry David Thoreau
The latest version of Fly for Scala has been released and is available at http://www.flyobjectspace.com/.
“If you have built castles in the air, your work need not be lost; that is where they should be. Now put foundations under them”. Henry David Thoreau
This third article about Software Quality is concerned with syntactics, by which I mean the syntax of collaborating components and systems, and the people that use them.
Many people involved in software development understand their business domain – i.e. they have business or domain knowledge. This is, for the most part, a good thing, for it means that they can have reasonable confidence that they share syntax and semantics with other stakeholders.
However, there are two common issues related to domain knowledge that bear some discussion. The first is the assumption that if we have sufficient domain knowledge, then we understand the problem. The second is a failure to recognise that in almost every significant software development effort, there is more than one domain that needs to be understood.
[...]