1. 33
  1.  

  2. 6

    That the author added real-life code examples to illustrate their standpoint is a great feature of this article and I also fully support their conclusion, but I can’t help but comment, as always, on

    good and expandable design from the start.

    Expandable design is not a good idea. If I see code that is more complex than it needs to be for what it currently does, with the reason that the extra complexity might benefit the code in the future, I believe that the author fell into the trap of hypothetical architecture.

    You only really know the optimal architecture for new features after those features were implemented. And as they should be, all code examples in the article are about refactoring code or processes that were proven to be problematic after continuing to expand the game.

    So instead of expandable design, what you really need is changeable design, and an organisation that supports it.