When I studied Computer Science years back, we’d repeatedly have the message that some high percentage of software development work (there wasn’t really much web development per se back then) would be code maintenance and changes. So not building cool new ground breaking stuff but fixing problems and making changes to code which could be your own, could be someone else’s, could be beautifully crafted or could be – likely as not – a complete dogs dinner. I don’t remember what that percentage was but it was high – 80 maybe?

Things have changed an awful lot since then of course. Now, with back and front-end frameworks of every variety, we can have an idea for an app, and get it up on the web where it can be accesed worldwide within hours. With this ease, there’s less cost and less risk with trying out new stuff so the pace of change is fast.

But arguably, the ability to work with what’s there is as important as ever. As ideas for features or improvements come through for the apps and sites which have taken off, developers need to be able to open the project, find and understand the code and get the change done. It’s engineering, pure and simple. [Stretched, clichéd metaphor alert] If I took my car to the garage because it was leaking oil and the mechanic told me they didn’t understand how the engine worked so they’d ripped it out and put a new one in and that had taken 6 hours and here’s the invoice, I’d be pretty narked. But some developers will do just that when they don’t get how an object works or feel that their way of doing it is better.

I’m not suggesting that we shouldn’t refactor, improve, optimise and bring new techniques into our code, but the ability to read, understand and work with what’s already there remains as important today as it was when the term software engineering was coined several decades ago.

That’s it, I’ll get my aged anorak.