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).

closed as too broad by Robert Harvey Jun 11 at 4:24

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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
  • 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 8 '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 8 '18 at 14:23

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 a 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.

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.