The Software Exists In Time

2023.07.14

Last updated 1 year ago

Was this helpful?

The Software Exists In Time

2023.07.14

Another issue that may lead to a confusing code is that we tend to ignore that our source code exists in time. I don't say we forget it but we don't take it seriously enough, with all of its consequences.

The code is continuously changing

One of the obvious goals of software development is that the program works correctly as specified. So the definition of goodness is based on the correct and tested functionality.

But is it enough? Is everything we implement a write-once-and-forget code? What do all the software developers in the world do each and every day?

They sit down to their computers and start modifying the code. They change the code that was written yesterday or last week or last month.

They modify the program that has worked well and has been tested!

So, is the above definition still good? I think it is not. It tells only that the software works correctly now. So we need to extend the project goal like this:

The program should work correctly now and at any time in the future.

Why is it better? Because it has the consequence:

We need to implement different features with the least possible dependencies.

Unfortunately, solutions like , , and , create many unwanted dependencies in the code.

Design for a long-term maintenance

Besides goodness, the other goal is the next deadline. All plans and estimations aim at the next deadline. The result is the following:

It may lead to quick & dirty programming.
Technical debt is collected.
It will seriously slow down the development and put future deadlines at risk.

It will be nearly impossible to work on technical debt later since we will always work on new features and bug fixes for future deadlines.

Everybody knows that the source code should be maintainable. But if we do not plan it, it won't be.

The goal is to maintain the software for years. The code must be maintainable.

As a consequence:

We need to choose solutions that are easy to maintain.

And the "next deadline" sounds like a secondary goal, considering all deadlines during the software's lifecycle.

Other benefits

These rules for maintainability primarily affect the development team. It is about the ability of the team to deliver error-free software on time for the long term. Needless to say, this affects the customer too.

But these rules have other benefits:

They work against the burn-out of developers who would need to work on an increasingly unmaintainable code base.

Also, they should decrease the number of developers leaving the team. Leaving developers would make the work on the project even harder and slower.

Last updated 1 year ago

Was this helpful?

The code is continuously changing

One of the obvious goals of software development is that the program works correctly as specified. So the definition of goodness is based on the correct and tested functionality.

But is it enough? Is everything we implement a write-once-and-forget code? What do all the software developers in the world do each and every day?

They sit down to their computers and start modifying the code. They change the code that was written yesterday or last week or last month.

They modify the program that has worked well and has been tested!

So, is the above definition still good? I think it is not. It tells only that the software works correctly now. So we need to extend the project goal like this:

The program should work correctly now and at any time in the future.

Why is it better? Because it has the consequence:

We need to implement different features with the least possible dependencies.

Unfortunately, solutions like , , and , create many unwanted dependencies in the code.

Design for a long-term maintenance

Besides goodness, the other goal is the next deadline. All plans and estimations aim at the next deadline. The result is the following:

It may lead to quick & dirty programming.
Technical debt is collected.
It will seriously slow down the development and put future deadlines at risk.

It will be nearly impossible to work on technical debt later since we will always work on new features and bug fixes for future deadlines.

Everybody knows that the source code should be maintainable. But if we do not plan it, it won't be.

The goal is to maintain the software for years. The code must be maintainable.

As a consequence:

We need to choose solutions that are easy to maintain.

And the "next deadline" sounds like a secondary goal, considering all deadlines during the software's lifecycle.

Other benefits

But these rules have other benefits:

They work against the burn-out of developers who would need to work on an increasingly unmaintainable code base.

Also, they should decrease the number of developers leaving the team. Leaving developers would make the work on the project even harder and slower.