On legacy (applications)

Legacy code is a synonym for unmaintainable code, monolythical systems and old technology.

In other contexts building legacy is something positive. Now building legacy is synonymous to leaving something valuable for a next generation.

Could we turn our legacy in something more positive? In a way we could put it on the balance sheet, in black.

How to approach this. Some thoughts.

Innovation while constructing

In most project delivering business value has the highest priority. Technological innovation and renovation are nice to have, and are often postponed under the pressure of time and money. Thus projects are slowly transforming the legacy code into even amorphous Corpus Logarithmum.

To mitigate this, in every project include some portion of technical innovation or renovation. Not as a nice to have, but as a must-have deliverable. This way make improvements and avoid turning functioning code into atrocious application molochs.

Investing in Software Archeology

99% of the stuff we do is building on existing code. Legacy code. And you are extending the legacy with increasing speed.

So we are a software archeologists (I think the term was invented by Grady Booch). We need to understand what the generation before you did. And improve it.

Software archeology isn’t just digging into code. It is digging into people’s heads. Souping up the knowledge in there. The knowledge they did not get the time for to put on paper. Booch calls it “tribal memory”. If there is anything on paper – or in some Folder, Document Management System, Drive, wherever it is growing mold. Don’t believe what is on paper.

Building for integration

We see many problems with old programs when they contain business logic that you want or need to reuse. At some point in time you will want to reuse what is already build. Then you must get to that logic in the legacy program. You’d better have a good interface. Or you will have to make an effort to open up your applications at a later date, which then mean a major operation on stuff you haven’t touched in years.

A insurance company had this very efficient life insurance system. All of the policy rules were coded in such a way that they were not accessible from outside these program. Then the internet came, and the life insurer needed to add channels to their business that needed access to the same policy rules. But they were not accessible. A significant re-engineering effort was required to break open the old application and allow the logic to be reused in other channel programs.

So it is best build new stuff such that we can always expose well defined interfaces. Service orientation may have been a big hype and it is behind us now, but the concepts of service-orientation, thinking in terms of service encapsulation and exposrue are evergreen. And by the way date from way before the SOA hype.

Building for automation

Legacy is mostly built with a past operating model in mind. Which means requiring a lot of manual labour to be executed by aging staff that have the knowledge in only their heads.  Therefore you do not just want to rebuild and extend legacy code, but you also want to replace the workforce  by programs. The programs that control your programs automate your development and operations. And automate your business of IT.

Building for longevity where needed

With today’s need for speed, a stream of throw-away software emerges. The life span of mobile phone apps seems to be less than a year.

Building backbone applications is different.

These are apps that can not be thrown-away in 3 months time. This is software that must last for years.

Therefore they must be maintainable.

You can’t afford a weekly app update. They must be right first always. Every bank knows what happens if the banking app shows an incorrect account balance. Twitter explodes.

It’s more like chess. You set up the opening with the end-game in mind. And you write down every move, so you can analyse the game later. See where you went wrong.

Future requirements

I was brought in by the CFO (also responsible for IT – not generally a good combination) of a small bank in Switzerland. They wanted to expand into Russia and Asia. So their system needed to support Cyrillic and Chinese characters. But it currently could not. He wanted to know what they needed to do to change their systems to support these character sets. So I investigated this for him. The bank’s application weren’t maintained for many years. The middleware and the database management system were very outdated. Beyond a point where migration to new technology was an option. Bad news for the CFO. And he for his shareholders. Hadn’t he cut cost on maintenance, the business might have been ready for expansion. Now they were hindered by their systems.

You don’t need to me psychic, but you can take measures that can prepare you for the future.

Google’s Documentation Style Guide – helping the writer in the developer

Google have published a style guide for their developers.

It’s a nice guide for all writers of non-fiction.

Some cute things:

On semicolons (I never know when to use) not much help (https://developers.google.com/style/semicolons)

Where to use semicolons is often a matter of judgment. Use them judiciously.

In the resources section the style guide refers to Apple’s and Microsoft’s style guides. (https://developers.google.com/style/resources)

Other companies’ style guides, such as the Apple Style Guide or the Microsoft Manual of Style.

Anthropomorphisms, which I like especially in documentation (makes them read like a novel, if done well), however not recommended by Google (https://developers.google.com/style/anthropomorphism):


Not recommended: A Delimiter object tells the splitter where a string should be broken.

Recommended: A Delimiter object specifies where to split a string.

Just one I did not understand (https://developers.google.com/style/headings):

Things to avoid in headings

Don’t use the following in headings:


Should you learn how to code?

Everyone in IT should know the basics of programming. (Also you should have installed some Linux distribution on your laptop. Even if its your laptop, it increases your understanding of the complexities of managing a platform.)

Program something

Program a crappy little program, you will understand more about the challenges of the programmer.

Derek Sivers wrote a nice article about why you should learn programming. https://sivers.org/prog
For him learning to code means self reliance and basic understanding are the main reasons.

Also experience the joy of building you own computer. I helped my son when he built his gaming computer. I learned at least as much as he did.

What language to start with

Derek recommends to start with HTML and CSS. Well, yes, agree of if you are interested in programming web sites. But HTML is such an ugly programming language. It’s like staring programming with BASIC. Before you know you think GOTO is a great flexible feature. While it actually is kitsch. I would rather start with Python, php or Java.

Build something useful in a very short time. Make it ugly. It doesn’t matter. Improve it step by step. Or start something new.

I like exploring programming languages.


I recently played with php. Built a small website showing photo’s from google images using random keywords.
Using MAMP.

Then played with python, programming an interface between Kindle and Evernote. Used Pydev.

Did some Javascript and node-RED.

A lot of Rexx programming. 

And Erlang.  That’s a hard one if you are not familiar with functional programming languages.

I learned a ton. I am always amazed what you can learn FOR FREE on the Internet.

Programming: a profession

Programming, a profession not a monkey task

A few years ago an IT manager said to me: for this programming job, I should be able to hire any monkey from the street.

I told him such an attitude would very quickly ruin his application, if not his entire business.

For an organisation that relies on software so heavily, allowing unmaintainable code to enter your applications is like accepting a loan your will never be able to pay off. You are building up an insurmountable technical debt. You can only hope you have some superb programmers around when the bugs hit the fan.

Programming profession

But for us programmers the problem is also about professionalism.

Coding is a profession. Good programming is a skill.

Some organisations want to have code done for 5$ per hour. Or so. Less than you would pay for a plumber. You would trust a plumber for that rate, why leave a programming job to someone for that rate? You are simply not serious about the problem at hand if you hire like that.

plumber programmer
Image by Sergio Fabara Muñoz CC BY

Democratization – the amateur and the pro

There is a tendency to underestimate the importance of skill.
Programming is democratized. That is good. Coding is not something mythical either. Amateurs can do it. Do it well. And enjoy it.

But for the problem in my organisation I need a pro.

Photographing is democratized. But for my wedding photos or for my business brochure I hire a professional photographer. Because he has a number of things extra, which I would summarize a craftsmanship and experience.

If you want stuff done you want good craftsmanship. A specialist you can talk to.

And by the way, ideally they should be at your desk and you at their’s. This is where outsourcing often goes off the track. Too little interaction.

Go pro

Cheap programming may work for throw-away apps. But not for high quality solutions that need to work be maintained for a couple of years or more. That stuff is built for the future. For maintainability.

By an expert.

Agile and Architecture

Do we still need Architecture now we have embraced Agile?

Can you drive a car without maintenance and without knowing where to go?

Here are some reasons why Architecture is still important.

Long term planning

Agile is about (software) delivery. Not about looking at the strategy.

Architecture is strategy. It is about looking at the longer term, about piecing pieces together, across deliveries, across teams, doing things in a  sustainable manner for the longer term.

About the direction in which things must develop. About anticipating change.

Going through the major agile notions in the context of architecture (see http://agilemanifesto.org/, http://agilemanifesto.org/principles.html).

Respond to change over plan?

Yes, wisely. Not respond to any change. Without strategy and horizon it is not possible to assess what response to change in the environment should be. Response can mean many thing: react (do something), ignore, stop, expand, …

Architecture provides a reference, also, especially!, in turbulent environments.

Customer collaboration over contract negotiation?

Yes. Again: wisely. And within your long term frame of reference. Customers may change their mind all the time. Some do, because they are uncertain. Or because they have no longer term vision.

Working software over documentation

Of course. Documentation should not be a goal in itself. More and more technologies allow us to generate documentation.
Without documentation no maintenance. Postponing or ignoring documentation will kill you in the not so long term, when change is necessary.

Teams choose their own tools and methods.

Fine, realising

  • Tools must be learned. If you adopt exotics tools, you may require exotic learning curves and exotic people in your team (read expensive, hard to find).
  • Costly support. Different tools for same purposes in many teams requires support for all the different infrastructures. They may lead to a proliferation of support staff and machinery.
  • Costly integrations. At some point you may wish to integrate tools across teams.
  • Using different tools limits cross-team pollination.

Teams use their own delivery cycle (sprints)

Fine. As long as in concordance with the other teams where necessary.

Continuous delivery of software drives customer satisfaction

Not sure. Prototyping is fine. But the advantage of showing early software also carries a danger: you can change you mind too often.agile and waterfall Also, nice for small projects, but in more complex systems, delivery of a single piece may deliver 0 value if out of context with the rest of the teams. Quick delivery of a new product by the product management team is great, but if the channel management software can not deliver it, it is of no value.

Changing requirements is always possible, also near the end

Yes. Change must be anticipated. Wisely, as said.

(What end?)

Close collaboration between business and IT

Yes. Finally. If agile has brought one great thing it is the penetration of the business into the IT department.

Best requirements and architecture emerge from the teams

Good. If teams can land on the requirements and architecture. Which is not always the reality.

Some governance is need to prevent proliferation of good ideas. The idea that there is one best solution, and architecture is invalid. Sometime the single best architecture is better because it is cheaper, can be delivered faster, managed better, etcetera. Architecture is a trade-off.

Teams regularly reflect on how to become better

Great. Prevent navel-gazing.

Simplicity–the art of maximizing the amount of work not done–is essential

Yes. This also includes the achitects’s tendency to over-architect and make things nicer than needed (gold plate solutions); of course I am exaggerating (not).

Continuous attention to technical excellence and good design enhances agility

Yeah. And this also means improving architecture and design while this may not DIRECTLY deliver business value!

Agile processes promote sustainable development.

(The sponsors, developers, and users should be able to maintain a constant pace indefinitely.)

Businesswise but also technically. Building technical debt will slow down progress in the (not so far) future.

Pitfalls of agile

When not practised wisely, agile pitfalls include:

  • Short termism. A backlog of quality items. Business value gets too much preference. Delivery over quality may lead to a backlog full of technical debt.
  • Islands. Lack of cross-team collaboration. Disparate goals.
  • Ever-drifting requirements. Great delivery but only variations of the same.
  • Navel-gazing teams losing bigger picture out of sight.
  • Cost of maintenance and tools; team members busy doing system management not software development.

Your thoughts?

Close Menu