Posted by Paul on 23rd May 2012
Well intentioned, but poorly considered efforts at code reuse can cause allsorts of maintenance pain – engineering best practice shouldn’t be applied unthinkingly. Although software reuse can be good (see Dry Principle, for example) it should only be applied where there isn’t too much variation from the common case.
Taking code reuse as an example, a good software engineer will judge what should be considered the common case and how much variation from it would result in poor application of reuse. That type of judgement often comes with the experience of having attempted reuse where it isn’t best suited!
Poor results often come where a good case for reuse hasn’t yet been established – i.e. where it is only anticipated there’s such a case for reuse. Before embarking on an effort to create generic, reusable code, the rule-of-thumb, ‘use before reuse’, normally applies. A corollary to this is that good quality reusable code is often factored from existing (well designed) code, or at least evolves.
Posted by Paul on 2nd June 2009
There are plenty of reasons why speedy delivery of a software product may be important to a business, and as a developer of software I have often found myself to be under pressure to quote and then deliver to over-optimistic time-scales. But if that software has to be maintained and developed further, as is often the case, then at least some thought should be given to the quality of the design.
Software quality has many concerns, with design quality being a tricky one to measure. I’m thinking here of those things that relate to the conceptual integrity of a system – cohesion and coupling amongst them.
Now, it’s difficult to address the conceptual integrity quality of a software product that has already been constructed with little regard for it throughout the development life-cycle. An engineer I used to work with tried to overcome the difficulties of explaining this to non-technical staff through the use of analogy. He would explain that addressing these qualities towards the end of the development phase is akin to trying to add eggs to a cake after it had been baked.
As another analogy consider trying to rework a badly written piece of prose (whether a business or technical article, story or novel); the quality of the piece is threaded throughout and within the text as a whole. In the same way, there are many features of software – most prominently in its structures and internal component/object inter-relations – which are threaded throughout the source code.
Returning to the prose analogy, there are features of badly written prose which are more easily addressed than others, such as bad spelling or grammar. But the structure of the prose is more difficult to address; rewriting sometimes being the only way forward since reworking can be more time-consuming than starting afresh and reworking is likely to leave remnants of the original poor structure. The point here is that quality and the intention to incorporate quality must, for the most part, be our purpose at the outset if we are to effectively achieve a quality result.
