1

I'm conflicted on this one

On the one hand, there's the YAGNI principle that states that you shouldn't write anything that you don't need right now

On the other hand, preventing problems is generally cheaper than solving them later on

For example, the moment you add a second if-else branch, you don't need to refactor it and design it the OOP way (and write more code). But if you foresee that keeping on with the procedural approach will land you and your team in a maintenance hell one day, you are arguably being shortsighted. It's not what a professional software developer should be, I believe

So there are cases when foreseeing is bad and there are cases when foreseeing is good

If so, how do I tell the two apart?

Greg Burghardt
  • 45,304
Sergey Zolotarev
  • 1,948

4 Answers4

4

There's a strong case for not going very far in trying to guess what might be needed in future.

Obviously, the truly "foreseeable" should be catered for now, but the issue with YAGNI is that a programmer might start trying to pre-empt a large variety of design contingencies before it has become clear whether any of these contingencies will actually apply.

Another mistake is to front-load too much design work, rather than adopting a reasonable phased approach. If you try and pre-empt too much design work, even if it is ultimately required, it's possible to simply become overwhelmed with managing all the complexity, such that you don't actually save yourself any work but instead overwhelm yourself with the task.

This isn't a suggestion to be short-sighted, but to distinguish between knowing future requirements and only guessing at the possibilities, and between making sensible preparations for the near future and exhausting your mental energy on the far future when you should be tackling the priorities.

As for "maintenance", there isn't usually a huge tension between code that is correct today and code that is maintainable in the future.

A procedural solution which is already correct and well-structured, is probably not made more maintainable by introducing what is often regarded as an OOP style.

A lot of developers, when they worry about maintenance, are either worried that the code isn't sound to begin with because they haven't fully got to grips with the complexity, or they are satisfied that it is sound but are worried about trying to remember all the details of the design in 6 months time.

The solution to unsound code is to spend more time on it, but the solution to remembering it 6 months later is often a more complicated issue that has no general solution besides adding more manpower and greater specialisation.

Steve
  • 12,325
  • 2
  • 19
  • 35
3

YAGNI is often used as an excuse for bad practices and cutting corners. What's missing from the calculation is an actual measure of the effort required to do the thing vs doing it the "simpler" way.

If you are in the practice of writing code in a OOP way, then you will write that if block the OOP way. It's not going to take you any more time than writing it a procedural way. When asked why you wrote it that way you might go into a explanation of code maintainability or the open closed principle and get a "YAGNI!" response.

Which might well be true, but that wasn't the reason you wrote that particular bit of code that way, that was why you write code in a OOP style.

You don't flip your styles around depending on some judgement of future needs unless there is some large time cost involved. It's just quicker to write everything the principled way.

When looking ahead you are applying your experience and knowledge to make the best solution you can. Always look ahead.

A "YANGI" discussion is either "I don't understand/like this code" or "You are programming too slowly". It's not helpful to say "stop foreseeing"

Ewan
  • 83,178
2

If you think you are going to need it, give me a reason why you are going to need it. A lot of it is common sense.

Say you write software for a car manufacturer that needs to handle different car models. If you handle a 2022, 2023 and 2024 model XYZ car, then you are going to need code handling a 2025 model. If a law change has been announced that takes effect on July 1st 2025 you are going to need it. If you want to be prepared for a model with six wheels, no, you are not going to need it.

Distinguish between “I will need” and “I might need”. What speaks against implementing something now is no clear reason why it will be needed, no clear knowledge what will need doing, no or little savings by doing it now vs later. Things that you need now should usually be more important than things you will need in the future.

On the other hand, you should avoid a design that makes future improvements harder of impossible without considerable benefit now.

gnasher729
  • 49,096
0

YAGNI should never be used an excuse for shoddy programming. Doing it right will make maintenance easier later on, when changes are requested.

On the other hand, preventing problems is generally cheaper than solving them later on

Except when it means adding extra complexity to the code to implement features that the customer hasn't asked for, and probably never will.

For example, implementing a multi-level "undo" function requires you to remember what changes have been made, in order to revert them. If the customer never asks for an "undo" function, then that's needless complexity.

So there are cases when foreseeing is bad and there are cases when foreseeing is good

Foreseeing is good when you know that you will need to implement a feature, but you haven't got around to that feature yet.

Simon B
  • 9,772