Software Development Since 1997: What Hasn't Changed | Digital Marmalade                               [Skip to main content](#main-content)  Think about how much has changed in software since 1997. Dial-up internet. Flash websites. Years of new tools, each one meant to fix the last. Digital Marmalade has built web and software products since then. We've worked with clients like The Telegraph, the NHS and King's College London. Most of the tools we started with are gone now. A few things never went out of date.

It's tempting to think good software is mostly about using the newest tech. Often it isn't. The teams that build things people actually use tend to get a few basics right. Again and again, no matter the year.

Understanding the problem still comes first
-------------------------------------------

This sounds obvious. It's still the thing most often skipped. Teams jump straight into building, because building feels like progress. Asking hard questions first can feel slow.

The cost of skipping this step never really changes, though. A team that builds the wrong thing well still built the wrong thing. Since 1997, the smooth projects have stayed the same kind. The ones where someone took time, early on, to understand what was really needed. Not just what was first asked for.

Good communication beats clever code
------------------------------------

A brilliant piece of code that nobody can explain becomes a problem the moment its author leaves. We've seen this happen with cutting-edge tech and with simple tech alike. The technology was never really the risk. Poor communication was.

This holds true with the newest framework or something ten years old. Clear documents help. Honest updates help. A team that says "this isn't working" early, rather than three weeks before launch, helps most of all. These things outlast almost any technical choice.

Small, steady changes beat big, risky ones
------------------------------------------

Big launches feel exciting. They also carry big risk. Since 1997, the safest path has stayed the same. Smaller releases. Tested properly. Shipped often. This isn't a new idea. It's just easy to drop under pressure. The teams that hold onto it under pressure are usually the ones that ship reliably.

What this means today
---------------------

None of this is a reason to ignore new tools. Better frameworks, faster pipelines and smarter testing have made real differences, and we use plenty of them. But they're useful because they support these basics. Not because they replace them.

Choosing a software development partner? Ask less about which frameworks they use. Ask more about how they handle the things that don't change. How they understand a problem before building. How they communicate. How they manage risk. [Learn more about our team](../../about), or see this approach in our [case studies](../../case-studies).

  [    Back to news  ](/news)

  July 2026 ###  [ How to Modernise a Legacy Web Platform Without Losing User Trust ](https://www.digitalmarmalade.co.uk/news/how-to-modernise-a-legacy-web-platform-without-losing-user-trust)

  Read more

  July 2026 ###  [ Why Cybersecurity Consultancies Need More Than Point-in-Time Assessments ](https://www.digitalmarmalade.co.uk/news/why-cybersecurity-consultancies-need-more-than-point-in-time-assessments)

  Read more

  July 2026 ###  [ What Makes a Digital Puzzle Platform Engaging for News Publishers ](https://www.digitalmarmalade.co.uk/news/what-makes-a-digital-puzzle-platform-engaging-for-news-publishers)

  Read more

  Allow cookies