The Curious & Frustrating Effects Of Time on Software

It ultimately led nowhere.

I found it passed to another part of the codebase. It was passed around a bit more. But there was no logic where this variable was used that actually made a difference. There were no comments related to it. It existed yet essentially did nothing.

This has happened to me more than once and it points to an interesting phenomenon in software.

The effects of Time.

How Time Effects Software

Time has the most impact of anything on our lives. We are all governed by it and there is no escaping it (despite what billionaires may like to think).

Software included.

Time effects software in a subtle yet dramatic way.

Over time, that once fresh dazzling new library you started using, loses momentum, becomes unmaintained and eventually deprecated.

Over time, that one person in the team who was the goto person in your company for that one app, leaves.

Over time, your motivations change and that once exciting project becomes dull and uninspiring.

It causes so many problem does blessed time.

This is why software has so many “best practices”. They are a strategy humans have adopted to try and fight against this inevitable nemesis.

Structuring your app well? It has many benefits but one is the advantage over time.

Developers will come and go but if they all adhere to the same structure, it enables one developer to pass over the baton to the next relatively easily and have some semblance of continuity.

Company coding styles? Again, this enables continuity despite the inevitable changes that will happen in personnel over time.

How Software Is Mutated Over Time

What about the software itself? Software is like a living entity in some ways. It is born, it develops into something, the growing period is different for every app and at some point it eventually dies. Some live only weeks, some live many many years.

A piece of software, usually originates from one person’s idea. They create this idea in the real world and at a certain point, if there is enough momentum, other people get involved.

Over time, ideas start buzzing around and some stick. The software mutates. It evolves. It grows.

It’s like it is passing along a conveyor belt and different people come and work at that conveyor belt either sticking on new parts, removing parts they don’t like or changing what is already there.

Whether this turns out well really seems to be up to fate or luck. It depends on the people involved. How they can work together. Whether they have enough ‘time’ to achieve what they want.

But it’s a curious phenomenon that this is how so much software is created. From the outside it seems somewhat chaotic but what comes out of it is sometimes incredible. Other times, and probably much more common, it’s all a bit crap.

Think Of The Software You’re Writing Right Now

If you’re working on a piece of software right now, imagine what it would look like to someone 10 years on the future. Quite a surreal thought right?

Will it make sense to them? Is it structured well ?Are there pieces of logic that require so much context it would make no sense to an outsider? What about variable names? Function names? Are there tests?

Will your piece of software survive the test of time?

Strategies Against Time

The best defence against the impact of time on your piece of software is adopting “best practices”. It may not thrill you to read that but people before you have experienced the same issues and the same pain so you would be wise to learn from their mistakes.

Best practises such as:

• Separation of concerns
• Using version control
• Writing tests
• Code style guides
• Using Agile methodologies (some will strongly argue against this I’m sure)
• Using well known design patterns

Benevolent Dictator Strategy

There is also the “Benevolent Dictator” strategy. This has worked well in cases like Laravel (Taylor Otwell) or Ruby on Rails (DHH). This is where there is essentially one person in control of a project and they make the important decisions along the way.

The one big benefit of this approach is continuity. This, at least in theory, over the long term should lead to a more cohesive and aligned piece of software as the person making the decisions has the most context. It should also lead to consistent design.

Obviously this doesn’t always work out. People also change over time. But there are these two big projects I mentioned that show that it can work.

Conclusion

Time is something curious and humans still haven’t really worked it out. Regardless, we have to live with it and it’s fascinating to watch the effects of time on software.

Keeping continuity on a software project over many years is really hard. Like REALLY HARD. The main reason for this is people come and people go and ultimately humans are the ones making the decisions that decide the fate of the software.

If five different people are making the big decisions along the lifetime of a piece of software then the likelihood is the software will look quite deformed by the end of it. Not just in it’s overall design, but the code too. Engineers can have really different styles in writing code.

Next time you start working on a legacy piece of software, have a deep look at the code and app and see if you can notice the different styles that have been implemented over the lifetime of that piece of software.

Subscribe to My Weekly Updates on Medium!

Enjoyed This Post?

If you found this blog post helpful, why not stay updated with my latest content? Subscribe to receive email notifications every time I publish.

If you're feeling really generous you can buy me a coffee. (Btw, I really like coffee…)

What You'll Get

• Exciting Discoveries: Be the first to know about the latest tools and libraries.
• How-To Guides: Step-by-step articles to enhance your development skills.
• Opinion Pieces: Thought-provoking insights into the world of frontend development.

Join Our Community

I live in the vibrant city of Prague, Czech Republic, with my family. My blog is more than just articles; it's a community of like-minded developers who share a love for innovation and learning.

About me

I'm a passionate Frontend Developer specialising in React and TypeScript. My professional journey revolves around exploring and mastering new tools and libraries within the JavaScript ecosystem.

Check out my LinkedIn and Github if you are interested.