Letters: The Invisibility of Software Design

Letters: The Invisibility of Software Design

By Richard Taylor

Overload, 12(61):, June 2004

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.

Richard Taylor

Your Privacy

By clicking "Accept Non-Essential Cookies" you agree ACCU can store non-essential cookies on your device and disclose information in accordance with our Privacy Policy and Cookie Policy.

Current Setting: Non-Essential Cookies REJECTED

By clicking "Include Third Party Content" you agree ACCU can forward your IP address to third-party sites (such as YouTube) to enhance the information presented on this site, and that third-party sites may store cookies on your device.

Current Setting: Third Party Content EXCLUDED

Settings can be changed at any time from the Cookie Policy page.