Other Developers' Code and what can a Software Engineer learn from "Rich Dad, Poor Dad."

Other people's money?

If you don't know "Rich Dad, Poor Dad," it's a Personal Finance book by Robert Kiyosaki and Sharon Lechter. It might be interesting to read depending on your tastes.

Some of the things I read about in this book were what Kiyosaki calls OPM and good debt.

OPM, or Other People's Money, is exactly what it sounds like; using capital belonging to other people to invest in more significant financial assets.

Good Debt, according to the author, is a type of OPM. The concept is straightforward and doesn't need much explanation, in my humble opinion. It's about making the difference between debt that will ruin your financial future and debt that will make you wealthier. OPM and good debt are a way to build things faster and wiser.

Other's Developers' Code!

Being a software engineer, I couldn't help but notice that OPM in Personal Finance is ODC in software engineering.

ODC = Other Developers' Code.

Not a single software engineer in today's world will build an application without using some external libraries (e.g. Open Source). Imagine the amount of work you will need to sacrifice in order to build something without any external dependencies. If you want to be the only unique master of your code, you'll need to build everything yourself.

In other words, imagine you'll never use external libraries to build, test, secure and deploy your apps, you'll never use any framework, and probably you'll need to build your deployment platforms. This is almost impossible.

As Developers and Software Engineers, we use Other Developers' Code every day. So why shouldn't we consider this a kind of Technical Debt?

You're never 100% sure that a library that you're using today will work for all your future needs. There are no guarantees that an open-source library will be maintained in the future, even the most popular ones.

Without this "debt," we will spend years reinventing the wheel and rebuilding every framework and every dependency we're using.

Why "Technical Debt" is always misunderstood?

If you Google "Technical Debt," you'll find tons of articles and blog posts about it. The common idea is that Technical Debt is the devil in person, but this is not (always) true.

An objective definition of Technical Debt is the consequence of taking shortcuts during software development to achieve short-term results.

Is taking shortcuts wrong?

Taking shortcuts can be done in different ways, and it's obvious that taking the right shortcuts can be beneficial, while taking the wrong shortcuts can be harmful. It's as simple as that. The real questions to ask here are:

Are you managing every risk you're taking?

Do you really need to take this or that risk when making a shortcut?

Are your code modular and abstract enough to make it flexible for future changes?

Should it be considered bad if you're creating a Technical Debt?

Most companies today have adopted DevOps, Agile and Lean practices. These practices are based on minor incremental improvements to reduce the time to market.

While using these practices, Technical Debt is an inherent part of the software development process: building MVPs, build-measure-learn, flexibility over planning..etc

It's not wise to describe Technical Debt using "good" or "bad", without understanding the approach behind it and putting everything in a larger frame to understand the bigger picture, from the business goals to the philosophy of the company.

Is Technical Debt inevitable?

Some years ago, a company building a monolith system with "Zero" Technical Debt could have been considered a success. Today, the same monolith system could be regarded as a Technical Debt trap in a world of microservices and cloud-native apps.

Was the company able to avoid this trap? Probably not. The tools, frameworks, infrastructure, and knowledge required to build microservices didn't exist back then.

Technical Debt is a tool. If you don't use it, it will use you!

I'm not advocating for writing poor code or designing bad architectures but these are a few things that summarize what I've said above:

1. Other Developers' Code benefits your technological and business growth as Other People's Money and good debt in Finance.
2. Technical Debt is ubiquitous; this is the nature of Software Engineering.
3. Technical Debt is okay. Like in Finance, debt can be used to your advantage if you know how.
4. Avoiding Technical Debt at all costs is not possible, it's even counterproductive: "Premature optimization is the root of all evil (or at least most of it) in programming." ~ Donald Ervin Knuth.
5. Technical Debt is a tool. If you don't use it, it will use you!