6

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

From the one side this may be bad business decision. From the other side it is certainly bad HR decision. Ancient masters achieved excellence precisely because they made or built their artifacts for for the future, for the generations to come, for the eternity. Maybe software developers can achieve similar mastery and excellency 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 determines the required level of generalisation and future-proofness for implementation of specific feature?

My domain of application is accounting and business software (backoffice).

TomR
  • 1,003
  • 1
  • 9
  • 17
  • 3
    Maintainability is not an end in itself, it is just a property that potentially (but not necessarily!) reduces long-term costs. It depends entirely on the goals of your organization whether “quick and dirty” or “clean” software is more valuable. We don't know your context and can't tell you what to do, and asking for resources (standards, best practices) is considered off topic here. – amon Jun 29 '17 at 10:10
  • "Software for eternity" - are you *serious*? Thats ridiculously unrealistic. – marstato Jun 29 '17 at 10:25
  • see [How would you know if you've written readable and easily maintainable code?](https://softwareengineering.stackexchange.com/questions/141005/how-would-you-know-if-youve-written-readable-and-easily-maintainable-code) – gnat Jun 29 '17 at 11:03
  • 3
    Maintainable code is faster to write, even up front. It is a false economy. Unless you believe maintainable code must be overly complex. – Frank Hileman Jun 29 '17 at 17:48
  • 2
    *"software for eternity"* == COBOL...go work at a bank :) – Dan Wilson Oct 08 '18 at 13:58
  • 3
    Remember that nobody but you is an expert on how much time you need to dedicate towards ensuring your code is well-written and easily maintainable. Your boss isn't going to be the one to suggest you spend more time in writing it well, for sure. Writing it quick and ugly is ultimately going to make all the things you write quick and ugly, even if you're trying not to do it that way. – Neil Oct 08 '18 at 14:23

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 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 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
  • 542
  • 2
  • 13
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
  • 70,664
  • 5
  • 76
  • 161