Yagni (2015)

I think coherency of implementation is a lot more important than YAGNI. For example:

  class Car:

      def honk(self):
          print('Honk!')

Cool, now we have a car, but it only honks. But we only needed it to honk, so that's fine.

  class RoadTrip:

      def __init__(self, car, destination):
          self.car = car

      def go(self):
          self.car.start()
          self.car.drive_to(destination)

Oh no, we built a car but it does nothing that a car does. Let's add this functionality.

  class Car:

      def __init__(self):
          self.started = False
          self.gps = []
          self.location = cool_app.get_current_location()

      def honk(self):
          print('Honk!')

      def start(self):
          self.started = True

      @property
      def location(self):
          return self.gps[-1]

      @location.setter
      def location(self, new_location):
          self.gps.append(location)

      def drive_to(self, location):
          self.location = location

Super easy. Except a different user of our library implemented this functionality already for a different reason, but in a different way.

  class CarEngine:

      def __init__(self, car):
          self.car = car
          self.started = False

      def start(self):
          if self.started:
              raise Exception('Already started!')
          self.started = True

      def turn_off(self):
          if not self.started:
              raise Exception('Not started!')
          self.started = False

  class CarGasTank(self, car):

      def __init__(self, gallons):
          self.car = car
          self.capacity = gallons
          self.level = gallons

      @property
      def empty(self):
          return self.level == 0

  class MotorCar:

      def __init__(self, engine, gas_tank, mpg, location):
          self.engine = engine
          self.gas_tank = gas_tank
          self.location = location
          self.mpg = mpg

      @property
      def started(self):
          return self.engine.started

      def start(self):
          return self.engine.start()

      def drive_to(self, location):
          distance = location - self.location
          fuel_required = distance / self.mpg
          if fuel_required > self.gas_tank.gallons:
              raise Exception('Not enough gas!')
          self.gas_tank.gallons -= fuel_required
          self.location = location

I've lost count of the number of times I've seen stuff like this. Sometimes the original implementation is in a different library that's hard to change. Sometimes other code rely on specific details of the original implementation so changing it requires changing that code too. Sometimes additions seem "out of scope" so they are actively pushed to dependencies.

It might feel like this is a process problem -- like there should have been better upfront design or communication -- but these "failure cases" are actually the success cases for code. You want code to rely on your libraries. You want to consider all users of your libraries when making changes.

The problem is actually YAGNI, because that mentality encourages us to churn out big, incoherent bags of functions when we should be thinking about code responsibilities and designing whole systems.

You can see this in action with JavaScript most infamously. Its standard library is extremely YAGNI, and it led to whole new programming languages being built on top of it because it was so anemic. The complexity has to live somewhere, and if you don't deal with it in a coherent and orthogonal way, someone else will have to deal with it and their options will be a lot more limited than yours.

Following simple mantras like DRY, YAGNI, and whatever else fits on a poster is the surest way to mess up your design. It requires thoughtfulness and experience, and there are no shortcuts.

Everyone likes to pretend they can predict the future for a while, to the point where they will stop at nothing to make it conform to their predictions. Then comes the part where they will defend their choices to death, no matter how much evidence to the contrary is piling up. Once you start seeing the entire chain of consequences, it becomes easier to discipline yourself; it's a process of growing up and taking responsibility.

> How much software development isn't either implementing the actual features or making the software easier to modify?

The key is the adjective, presumptive. YAGNI is about features that aren't needed now and it's uncertain whether they ever will be.

Do you have some pointers to important papers of this field of study?

I built the same thing I'd planned originally, so the point is moot. YAGNI does nothing to stop you from misunderstanding the problem. And in the case of my problem, the metadata was fresh anyway. Generating it from scratch would have the same migration cost, but all the original tooling existed so I wouldn't be building the feature from scratch.

If the point is "what if the whole concept was wrong?" then sure, you got me. But the point is that I _did_ follow a YAGNI mindset and paid a considerable cost. Even if I had built the wrong thing, that doesn't negate the fact that technical debt had accumulated and prevented me from doing the thing I actually needed to do.