To me, as a developer, this is probably the most important rule of thumb there is:
Before writing any code, design, design, design.
And yet, it's the kind of the advice that always seems to matter most when you want to follow it the least.
Time Crunch
We've all been here - your stakeholders are asking for something to happen in a period of time that's at least a little too small to be comfortable, and getting the work done is painted as an emergency. This is the likely the last place you're going to feel like taking the time to sit back and think things through carefully - you don't have the time or resources to spare for that! And yet, this is perhaps the most important time to do just that.
There are many ways to stifle productivity. It might be a lack of monitoring that makes tracking down bugs (or even realizing they exist) near impossible. It might be scale issues that bring the development cycle to a standstill. It might be a plethora of bugs arising from misunderstandings about the system one is working with. The list goes on and on. But there are essentially two ways these issues are uncovered - either by thinking the problem through and creating a clear design, or by finding these things after building something. In the latter case you still end up having to go back and do the design, it's just that you only got there after doing a lot of throw away work. Obviously, when there's a time crunch, doing as little throw away work as possible is of the utmost importance.
Now, even if you do throw together a design, it's often tempting during a time crunch, to put off worrying about design elements focused on longevity (things like scalability, extensibility, etc) because you feel like you just need to get something working now. Yet emergencies are rarely isolated events and usually end up extending across many, many different weeks as new features and products are required to truly dig a project out of the hole it finds itself in. Therefore ensuring that your productivity remains high over the long run is a much better strategy than trying to get through the current emergency by taking on technical debt that reduces productivity in the next one. You have a long road ahead of you - build for it.
When Everything's Easy Peasy
The opposite situation is also one where it will be hard to follow the rule of think before you code. You know the situation - you're dealing with a problem you know so well you feel like nothing can really go wrong and you can just do everything on instinct. This assumption, is a hypothesis and just like in the case of the time crunch there are two ways you're going to test that hypothesis - by either thinking things through or by building something that may prove you wrong. For anyone who's done development, you'll know that no matter how well you think you know a problem, anytime you're doing something new there are little details that can quickly derail well intentioned plans. Therefore, once again, to avoid throw away work, just take the time to think things through carefully - otherwise you'll be setting expectations to your stakeholders that suddenly, out of hubris alone, you won't be able to meet.
When You Just Want to Get Your Hands Dirty
Now you may ask, doesn't all of this fly in the face of the "fail fast" mentality? Not at all. Remember, a clear design, is more often going to be a series of questions that need to be answered than anything completely concrete. So even in the case where you're just wanting to find your unknown unknowns as rapidly as possible, taking the time to think things through carefully is important. If you don't, the "unknown unknowns" you discover may simply be answers to questions you could have answered at the outset with a little bit of thought, once again leaving you with unnecessary throw away work. Put another way, to guarantee that you're actually going to find things that lie outside of the scope of your understanding of the problem, you have to clarify your understanding of the problem first.
To summarize all of this, clear designs help you boost productivity, avoid unnecessary throw away work, and establish better expectations. In the end there are only two roads to discovering what's in your best interest - up front in thought or after you've built something you now want to get rid of. So, think first and then build something beautiful. And remember, the value of that thinking often scales proportionately with the pressure to skip skip it.
Comments