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.
A loosely coupled system is one where the different parts can interact with each other through well-defined interfaces, without having to know the internal details of the other parts.
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.
This post is for paying subscribers only
Sign up now and upgrade your account to read the post and get access to the full library of posts for paying subscribers only.
Sign up now
Already have an account? Sign in
You’ve successfully subscribed to Architecture Notes
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Success! Your email is updated.
Your link has expired
Success! Check your email for magic link to sign-in.