6

From time to time I feel exhausted in my software development efforts because I am pressed to think and develop in a very specific and very short-term manner. One client here and now requires one feature and I should implement it for him. Neither the client nor the management of my company are interested in investing some time and effort in investigating how can we make this feature adaptable and more general (e.g. introduce configuration instead of hard coding the one branch of a feature) for other clients or for future use.

On the one side, this may be a bad business decision. From the other side, it is certainly a bad HR decision. Ancient masters achieved excellence precisely because they made or built their artefacts for the future, for the generations to come, for eternity. Maybe software developers can achieve similar mastery and excellence if they are allowed to build software for eternity.

So - are there technical criteria (best practices, industry standards, etc.) for building maintainable and evolvable software, criteria that determine the required level of generalisation and future-proofness for implementation of specific features?

My domain of application is accounting and business software (back-office).

Martin Spamer
  • 538
TomR
  • 1,009

2 Answers2

9

My rules of thumb are:

  • I drive my code with Unit tests to keep it focused on the actual requirement, it also means as I evolve the code through each of these following steps I can be confident it will remain correct.
  • The first time I need some code, I produce the simplest possible thing that will work; I will follow the KISS Principle and SRP with regard to class and function decomposition. I will generally define `constants rather than using parameters or inline values.
  • The next time I need the same or similar code, I will generalise the existing code to make it reusable. I'll be applying ISP and LSP as necessary. I'll generally use my IDE refactoring features to extract methods or classes as necessary to maintain SRP. I'll introduce parametrisation as necessary and pull out the interfaces when extracting a new class.
  • The third time, fourth time, etc. for the full lifetime of the development. I will refine the abstraction. I add additional classes to strictly maintain the Single Responsibility Principle to guide their creation. Since I've previously applied ISP I can now I'll be applying DIP.
Martin Spamer
  • 538
1

Nor client, nor management of my company are interested in investing some time and effort in investigation

There's your answer. To be fair they will expect a lot of things that they don't state as requirements just because 'every website/app/report/whatever has that, I just expect it as default' so some forward thinking is required.

If your boss/client is happy with your velocity then all is fine. If not then you either have to push back and get those requirements stated so they realise up front what they are asking for is complex. Or type faster.

Of course there is the problem that you may find you are spending all your time doing boring maintenance tasks even though your boss is happy.

But at that point the solution is to hire someone else to do the boring bits and get your boss to give you just the good bits.

Ewan
  • 83,178