Later equals never.
I feel like this post on Why You Won’t Fix It Later should be required reading for new software developers.
There will always be deadlines, and there will always be pressure to deliver fast — especially in the startup world. You will often find yourself saying, “I can fix this later.” In reality, later doesn’t exist.
If you build something in six weeks that should have taken eight to ten if you were doing all the right things (unit tests, comments, not cutting corners), it is extremely difficult to get that time back in the future. When you deliver that new feature after six weeks, and everything appears to be working, it’s now time for the next thing. It is rare to be in an environment that allows you to spend weeks fixing all the corners you just cut. All of that tech debt is completely hidden from anyone outside of engineering, so it takes a very understanding management team or client to get any of that time.
As programmers, we can try all we might to prevent new features from outpacing our desired standard of quality. There will be times where you exist in a happy equilibrium, but the reality is that there will be times when you’re asked to move faster than you’re comfortable with. We should be doing everything we can to make all stakeholders aware of the consequences of moving too fast, but sometimes you just have to ship.
What can we do?
The obvious solution is to always have enough time to architect things the way you want it, write all the unit tests, document, etc. If you know there isn’t enough time, the first step is always to work with the stakeholders to see if the date can be moved, features can be cut, or if specific designs can be simplified. There are countless posts out there about the importance of quality, and ways to create a culture that prevents this scenario from ever happening — but I’m going to talk about what to do when you find yourself in the “later” situation because I personally don’t know if that perfect world actually exists.
When you start thinking “later,” you have to think of the consequences of the case where later never comes. You have to be deliberate about where you are sacrificing quality. How important is this thing to the success of the app? How many users could potentially be affected by something going wrong here? How devastating is it if something fails right here? Is this something that is likely to change? Are there other features that will build off of this one?
You can’t let things slide that are too important to the success of the app, or in places where failure means loss of work or data. Sometimes you know something is wrong, but it’s something maybe 1% of users will see and it’s only a wonky animation. That can wait — file a bug.
Regardless of how fast you’re trying to move, you have to write some unit tests. However, you could limit them to the most important parts, or the critical workflows. Make the quality engineering team aware of areas they should focus on, or things you’re particularly worried about. They should know about places where you feel you’ve had to sacrifice.
Track everything. Any time you have the “later” thought — write it down. Anywhere you sacrifice, anywhere you cut corners — write them down. Get all of it into your issue tracking software. If somehow you are fortunate enough to get some time to reduce tech debt, you’ll have a list of what needs to be done.
Finally, make the stakeholders aware of what is being sacrificed. It isn’t only the quality of what you’re building right now. It will likely impact the quality of future features, or it will cause slowness in the future when you’re working around things that weren’t built properly the first time around. Fight as hard as you can to schedule time to fix the most important or most glaring issues.
If it sounds like I’m advocating for this kind of development process — I’m not. I wish this kind of thing would never happen, but in my experience it is something that everyone has to deal with at some point. You should have a plan ready for minimizing damage, and this is just the thought process I use.