Antipattern: We'll buy it when we come back

After all, what does this have to do with planning in general and/or software development?

This antipattern is associated with a common behavior experienced by many of us as children when we saw something we desired, but our mothers, due to impossibility or lack of desire to reward us, would deceive us with the famous phrase “We’ll buy it when we come back” (This in Brazil, in your country, there might be another expression, but the behavior seems to be universal.) Even in adulthood, I observed that this is often triggered when an individual or a team, within a very short timeframe (due to contractual issues, for example), decides to quickly implement a feature, neglecting best practices and jeopardizing long-term sustainability. Inevitably, this creates technical debts1.

Even though it may seem obviously logical after a simple rational analysis, the number of times this occurs in companies (especially startups due to limited budgets) is surreal. Throughout my 15 years as a software engineer, I’ve seen this happen more frequently than rain in the arid hinterlands. I’ve witnessed it firsthand and heard accounts not only from software engineers but also from professionals in other fields (even those unrelated to IT or exact sciences) as something so simple… and, I believe, due to its simplicity, we sometimes fail to give it the importance it deserves. But mark my words, remember this general rule:

Technical debts have compound interest.

The idea is “do something and see what happens,” which is a real shot in the dark. Even though it’s very risky, it’s widely used as a side effect of poor overall planning. I’ll talk about these plans over time here, and there are various reasons for it. However, IMHO2 this antipattern is responsible for many projects, after a few years, having to be thrown away and redone from scratch because everyone forgets the nature of technical debts. In my view, technical debt behaves exactly like using a credit card, only the interest rate varies in this case.

Playing soccer on a PS3 with a friend and chatting about software development, at the same moment we were discussing the poor practices that some startups use in their daily routines, with perfect timing, we linked it to the mentioned maternal behavior. What actually makes me label this as an antipattern is the simplicity and depth of the problem. And here’s the catch:

God, I, you, and our subconscious know that “we’ll do it later” is a euphemism for never. And just like when we were children, unintentionally, we tend to fall into this parable until we taste the bitter flavor of compound interest in our lives.

Phrases that indicate you or your team might be using this antipattern:

Even ChatGPT seems to agree with me (lol):

Chatgtp about antipatterns

The correct pattern is ALWAYS to first understand the essence of the problem: In this case, the constant and inevitable changes in the market. Once that’s understood, and knowing the impossibility of stopping the change, we adapt to it: With a bit of common sense and using the analogy of good financial education, we conclude that it’s just scheduling a correction or adjustment in a timely manner. By not doing this, the antipattern is activated and materializes, negatively impacting the pocket of the person responsible by charging compound interest.


References and citations.

  1. The term comes from a metaphor inspired by the concept of debt in the finance and business field, applied to the software domain. 

  2. IMHO: “In My Humble Opinion”. 

  3. NTP: Normal temperature and pressure. 

  4. “Because there are many who are careless with themselves. And carelessness never yields good results: what needs to be done today should not be postponed until tomorrow.” (Superior Rational in “Universe in Disenchantment: 162H”) 

Discussion and feedback