It is very possible to create a box where software is forever broken. You create insane amounts of headache, forever, by not understanding when dev gets pressured to pave over or code around problems without addressing the core problem causing your pain. This occurs most often in software development in 2 specific situations. The term is technical debt, for when you end up in this problem where everything is built on top of bad workarounds. There’s a lot of analysis on why software ends up in this state. The reasons are boil down to; your software isn’t working well because:
- A Prototype gets taken into production – prototypes should take shortcuts! Production cannot live with those shortcuts when it scales up (non-software people always think you can just “fix it later”).
- When dev aren’t given time or expertise to investigate, then understand, then fix root cause…so instead, the approach is called “programming by behavior” ( You know this is occurring when you hear, “it works, and we’re not sure why” which really means, “it works, for now, it’ll break in the future and everything we build on top of this Band-Aid will be fragile as well)
- When dev doesn’t have sufficient time to do fix problems 1 or 2 – this has 2 causes:
- Saying yes to everything – which is the same as lying but feels better. Or,
- Pressuring development at all costs to deliver to a date, instead of delivering to a quality bar – for example a solid, dependable, methodically tested set of features…This one requires focus and executive brains (define features in advance) and balls (stick to the aforementioned feature set).
This point can get dogmatic, so I will skip the rest of the diatribe.