How I Meet Deadlines While Maintaining Code Quality
Cutting corners to ship code as fast as possible is a necessary evil. But, there is a reason they call it “Tech Debt”.
Deadlines means revenue, and more revenue means more money for everyone. Unfortunately, when left unchecked, the cost of the shortcuts we take stacks up like compounding interest which explodes so fast that we can’t ever catch up.
“So when is it worth it to take the shortcut?”
[emaillocker]
There is no single answer – but, there are a few principles that can inform your decisions.
Always Be Refactoring
Balance means prioritizing one thing today and the opposite thing tomorrow. It is negligent to consistently prioritize feature development over code quality.
Let me say it again. You should be fired if you allow your team to consistently prioritize feature development over code quality.
Temporarily accepting poor code quality to support feature development is perfectly understandable – but after meeting your deadlines, swap your priorities. When you find yourself in an endless march of feature development, get more developers or a new technical leader that has the strength to push back – all the way to the Board if necessary.
Start Thinking In Terms of Life Cycles
At some point, you will throw out your code and start over. It may not be tomorrow, but it will happen. And this means that it’s never a good idea to overemphasize quality.
There are natural points in software development when the requirements have become completely different from what they were when you began. Simply put, you started off designing fans but sell underwear now.
I promise, whatever infrastructure your company starts with will not be what you need in 3 years. It won’t even be close.
Protect The Integrity Of Your Data
Not all shortcuts cost the same.
The integrity of your data is more important than anything else. When a bug or misguided feature deletes records from your database – fix it. Like, yesterday.
Using a plastic bag instead of a glass window does not have the same impact as skipping a foundational wall. Nothing important depends on the window, but your house will fall down if the weight of the roof isn’t supported.
I’m astounded by how many teams introduce code like “If null pattern do x, else do y”. Instead, add the record in the database and skip the crap code.
Keep Your Delta’s Low
Release small, incremental changes – always.
Even the best developers can fall into a habit of shipping too much code at once. I’ve certainly done it – and not just early in my career.
It can get messy when we release too many features at once. Sure, it’s exciting to release a major patch with multiple features, but if everything suddenly stops working, you’re going to have a hard time figuring out the issue.
Small releases can be rolled back without impacting the overall product and/or blocking others. Plus, frequent deploys will make your deadlines significantly less frightening and more measurable.
Treat Bugs as the Highest Priority
Bugs are not inconveniences, they are ticking time bombs.
Develop the discipline as a team to stack bugs on the top of the development queue as they come up. I know it’s hard to get buy in across the organization, but I promise, it’s worth it.
Sometimes we ship knowing we have bugs, other times they show up after the deadline. Either way, make a point of resolving bugs before moving on to new features.
Reclassifying a bug as a feature to deal with later is an acceptable resolution for me – as long as the bug isn’t throwing exceptions or corrupting data.
Pro Tip! Get Agreements From Top To Bottom
A huge part of being a technical leader – be it CTO or team lead – is educating everyone you work with about the process of creating technology. The more transparency you create, the better requirements the organization can create for the engineering department, and vica-versa.
Invest the time to explain the concepts in this article to everyone you work with. The CEO, the marketing specialist, and the engineering intern.
Then, when everyone is on the same page, make agreements with your teammates to support proper balance.
For example, I typically work with my team, including my CEO, to commit in writing to dedicate at least 20% of our engineering resources (on average) to refactoring.
And yes, I have walked away from a job when my CEO refused to honor those commitments.
[/emaillocker]
