ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

pinLetters: The Invisibility of Software Design

Overload Journal #61 - Jun 2004 + Letters to the Editor   Author: Richard Taylor

Dear Mark,

I read your editorial in April’s Overload with a sense of depressing agreement. I have been in the industry for around ten years and I have worked in most phases of the software development cycle, from requirements through to some postinstallation customer support. I have worked as a programmer, a designer and as a consultant advising companies on development strategy and technology policy. I think that I am just getting to the point were I can understand what is going on and might have something to say about it.

I have been appalled by the lack of learning from experience that is evident in the industry but I am not sure that it is entirely down to the practitioners. I am beginning to think there is a structural problem with IT that exasperates people’s tendency to want to reinvent everything and I think that it contributes and fuels the ‘follow the hype’ climate.

I think that the problem lies in the invisibility of software design in the delivered product. I think that this invisibility has at least two important consequences:

Firstly, it means that good design is not recognised by the users because they can not see it. There is no end-user pay-back for elegant design. Contrast this with civil engineering where design is very visible e.g. it is simple to see that the Millennium Bridge has a wonderfully elegant design. This means that the industry as a whole does not place much emphasis on quality of design, so practitioners do not see it as important either. Therefore if it is not important why learn about how others have done it in the past?

Secondly, it means that it is difficult for those that do want to learn to know where to start. You can gain a great deal of information about civil engineering and structural design by looking at buildings, bridges, etc. In fact the conversation of many architects will be peppered with references to this building or that bridge.

Things are different for software engineers, there might be brilliant examples of software design installed on the computer I am using right now and I would never know. Even worse than not knowing, even if I did know I could not look at them because the source code will be secret.

This issue of secrets constantly nags at me. I think that the software industry’s obsession with intellectual property is an important reason for the glacial pace of its advance. As an industry we keep things private and secret more than any other (at least in my experience). How is a rookie programmer supposed to learn how those that went before him did things if everything they produced is hidden behind a cloak of secrecy? Unless he is lucky enough to work in a very experienced team he is left blind. This point is made clear in your editorial: unless I am lucky enough to know your friends how could I know that they had solved the problems of the transactional programming model 25 years ago? It is easy to see how medieval architects solved the problems of load on cathedral walls, you can go and look at the flying buttresses!

One light on the horizon is the increasing use of Open Source Licensing. This has led of a large body of software being made available for those that want to learn. I for one have found that I have learnt more about software design from my involvement in a number of Open Source projects in the last few years than I have in most of my professional programming jobs. I have also found that I am more motivated to do an elegant design and professional coding job if I think that many people are likely to look at my code. I realise, that as a professional, I should always be motivated to do this, but I, like most practitioners in our industry, am only human.

So my advice to a new programmer that wants to “stand on the shoulders of giants” rather than be condemned to “reinvent the wheel” is this: Ignore just about everything the software vendors tell you, listen to the old hands on your team and spend some of your spare time reading and contributing to Open Source Software.

Regards
Richard Taylor

Overload Journal #61 - Jun 2004 + Letters to the Editor