Software as a House – Programmers as Architects

How old is your house?

Mine is around 20 years old. When we built it, we had cable turn through the walls to connect televisions in most rooms. However, we didn’t anticipate wanting to have an Internet connection in every room so we didn’t have network cables strung through the walls. When we decided to add them, it took more work to get those cables into place than if we had done it initially. Now, of course, we have a wireless router, and those cables are largely unnecessary. Imagine if our house had been 100 years old. There would probably have been no provision for air conditioning. Or 200 – no planned indoor plumbing. Each new technology that we wanted to have added to the house would have required significant rework, and some of it would have involved “infrastructure” changes.

Of course, even though the house is only 20 years old, various pieces have needed repair or replacement. Oh, and we’ve finished off a level of the house which was initially unfinished, added a room and a deck and a third garage stall. And then there is the “updating” which happens – the new light fixture which replaced the broken one now doesn’t match all of the other working fixtures, so we buy everything to match.

Yes, when you own a home, you know that there are operating expenses, maintenance costs and then the costs to update the house over time. It’s expected. If you don’t plan for it, you will either be surprised by a large expense, or you will let the home deteriorate.

Recently I’ve been talking to customers who are in the process of evaluating their software and deciding how to change it. And, as I’ve done so, I’ve begun drawing analogies between houses and software. Oh, sure my title includes the word “architect.” I know that “architect” is most commonly used when talking about the professionals who design buildings. But the common thinking patterns between building architects and software architects pointed themselves out to me quite a bit recently.

Most software owners realize that, in addition to routine maintenance, they should also expect to pay for enhancements over time. We know, when we write a software package, that we won’t know enough, or have enough time, to get every desired feature in version 1.0.

Fewer software owners, however, give enough thought to the need for infrastructure revision as part of the lifetime of a product. The first time an old piece of software needs significant infrastructure revision, it is likely to be an expensive proposition. At that time, a good software owner needs to decide if the architecture of the product can handle the refit.

A programmer becomes an architect, in essence, when he or she decides to plan for the unknown, and to anticipate needing to make changes over time. If the piece of software needing to be changed in the previous paragraph has significant value that cannot be easily reproduced, the architect must find a way to wrap it, or deconstruct it into components, so that the value is preserved. And while preserving the value, the architect must also plan for an unknown and unknowable future. What if we want an entirely different user interface? What if we have to interact with another machine? What if this product needs to be audited?

There’s been a lot of talk over the last decade (or more) about “modernizing” applications. Why do we care about this? Fundamentally we care because, like old houses, the applications have quite a bit of value. We want to retain that value, but we also recognize that things have changed and we need to fit into the new characteristics of the world we live in now.

For this reason, many people who were “just programmers” in the past need to think of themselves as “architects” now and need to approach their jobs that way. I remember that the first programs I ever wrote were not intended to have their source code touched by anyone other than me. And even I found it hard to make significant changes to them, because when I wrote those first programs (probably text-based computer games, if I recall correctly) I was a novice. (Ah, the free-wheeling, wild-west programming days of the 1970s.) Some few businesses might still have software around that was written this way, but most replaced it with software written by a professional, who knew enough to make their code more readable and more easily extended. Yet still, large applications were written, especially over the long life of the AS/400 and IBM i platforms, which were not given the full treatment of an “architect.”

Today’s “programmers” should be planning for their structures to be relatively permanent. With this in mind, we need to plan for change. If we’re given the opportunity to revise the infrastructure of an application, we should carefully consider how we can use all of the tools at our disposal to revise it so that future revisions will be easier. This will make the application more valuable to the business which uses it and more flexible to the unknown requirements of the future.

 

Comments

[David Andrucuhuk]

Deep bows to you on this article as it is what I tell my clients daily.

While the labels programmer and architect are often considered one in the same, in reality, they are not nor is the function they are expected to perform in the workplace.

Best wishes to you and your family during the holidays.

[Bob LeMay]

One problem is that too many "homeowners" (read "businesses") don't want to take the time or money for an architect and blueprints (read "analyst" and "design"), but want to rehab on the cheap.

You get what you pay for (in time and money).