3 ms·

If your name is Alice and you live in Wonderland. Or Harry in Hogwarts. In the real where requirements change constantly, libraries that you rely on rely on le

If your name is Alice and you live in Wonderland. Or Harry in Hogwarts. In the real where requirements change constantly, libraries that you rely on rely on left-pad, budgets are short - or hell people just learn to write better code - so the old need to be refactored - the debt accumulates. Code debt is like entropy - always goes up. The normal state of a software project is under staffer, under budgeted, in constant flux requirement wise and for yesterday. Doing it right with reviews, refactoring, consistently is a luxury. You can try to have a process that minimizes chaos to minimum, but every project will devolve into unmaintainable mess. You cannot afford to be pure while you have the huge state monad called rest of the world that gives its best to crush you.

sgift 10y ago
Like every "we are doomed" answer there's a core of truth in here: If something is used and/or changed it will probably break down. Given that and trying to use it as starting point for something more helpful: Sofware is nothing special here. Your things will - depending on their quality - break down with time, especially when you tinker with them and/or use them. You can push this further into the future using maintenance, repairing damaged parts and so on, but at some point you will have repaired so much that you will in essence have a new thing, not the old thing anymore. The task is to balance your efforts with your use case. An engine which has to work for one formula one race is constructed very different from one which has to work 200 or 300k kilometers. Again, software is nothing special here. If your software has to work for one run "doing it right" may be a luxury. If you need your software for years to come your luxury becomes necessity.