Paying Down Technical Debt
Ask any five developers what “technical debt” is and you’ll likely get five different answers. To some, it’s an outdated framework and/or coding pattern. To others, it’s code that’s hard to work with. To still others, it’s the result of cutting corners to meet a deliverable. Let me throw out another definition: all code is technical debt.
Before you get out the pitchforks, give me a minute to explain. That outdated framework?
Infrastructure Monitoring
As software developers, we like to build cool new things with fun technology and the most cutting-edge techniques. But when applications are released to production, things can get hairy pretty fast. There are plenty of great tools to help you track uptime (Pingdom) or allow you to sift through traffic logs (SumoLogic), but sometimes the infrastructure will cause issues that aren’t readily apparent in these tools. That database query you wrote will misbehave when there’s a lot of data.
Architecture Decision Records
How many of you have gotten deep into debugging some production problem and said “Who wrote this crap?”? How often did it turn out that you yourself wrote it? At the moment in time that you designed the thing (system, database, algorithm), your choice probably made sense. But once customers got a hold of your software, realities set in that exposed a flaw in your design. It’s because when you made that design you were in the wide part of the Cone of Uncertainty.
Choosing the Right Architecture
There is no perfect software architecture.
Architecture, like economics and life, is all about trade-offs. The solution you’re building has to deliver both the functional and non-functional requirements the stakeholders need. It doesn’t get said enough, but the engineering team is also a stakeholder in the project. The functional requirements are easily understood: they are the specific things about your application that delivers the business value and makes your company money.