Technical Debt

How does technical debt accrue? Most people would say bad engineering. What is bad engineering? Inflexibility? Is one system engineered correctly to do one thing trying to do something else considered bad engineering?

We are going to cover a few ways technical debt is accrued and how you can pay it down and where you should start.

Myth of Design Patterns

Engineers often quote design patterns which are solutions to known problems. In software engineering a lot of problems have a similar shape but constraints often add extra dimensions that make things much less cookie cutter.

Design patterns are only as useful as the problems they are designed to solve.

Blindly following a design pattern is similar to painting by numbers. Much a kin to chess beginners following certain openings to the letter when things go off script things tend to get bad and you quickly wish you could go back to a few moves earlier. I have been there countless times both in chess and building software.

Early on when you are standing up your system its important to keep things simple and as loosely coupled as possible. This is both in architecture and implementation.

Unless you are replacing an existing system you aren't entirely sure where the product might go so its important to really understand your domain and where you might pivot to tomorrow.

So while the product or service you are building is still evolving its important to think through potential extensions and problem areas in the future. Also architecture for 4-5 years of growth which gives you enough to see where your design didn't work and gives you time to fix it. Code changes take weeks, design changes take years.

If you have a problem that aligns perfectly with a known design pattern, take the win and throw it to first base, resist the urge to over engineer.