Draw Before You Code
Okay, I have to admit: I just wasted a whole sprint refactoring.
That’s no big deal in general: as long as it’s worth the effort, we really enjoy investing in quality at mySugr. But if you’re the same kind of programmer who not just has a lot of freedom at work, but also likes to produce really good code and architecture, you might end up with a big number of incremental micro-improvements, too — and a lot of wasted time!
As we write code, we learn constantly about new scenarios and potential for improvement of the feature we’re implementing. That’s totally normal — you can’t know everything in advance. But it’s not easy to cope with frequent change and by no way is it efficient; the same way we don’t like our product owners to change their opinion three times in a sprint.
Therefore: Draw before you code!
It only takes a few minutes. Just grab a piece of paper and draw your classes and the relations and interactions between them — just like that! When you think about a scenario and it’s not solvable with your architecture, drawing can help to work out the kinks.
Sure you have to invest more time, sometimes even a lot. That’s actually good because if you noticed the flaw during coding, you’d have to change your setting totally from “yeah, coding!!!” to “oh stop, I need to rethink this and I probably have done unnecessary work” — which is very uncomfortable. Every time you face a situation like that, you have to change focus, and sometimes you even have to make shortcuts or compromises.
In contrast, when you invest a few minutes beforehand to spend some thoughts on your architecture and probably discuss it with your colleagues, you will have much higher confidence about what you’re going to write. You’ve already taken all the edge cases and scenarios into account. Now you can concentrate on just writing down the classes and you don’t have to move stuff around until it “looks good.” Most likely, you’ll end up with much less distraction and a lot of time saved — welcome to the “zone!”
The later you catch a flaw, the harder to fix.
It goes without saying that it makes sense to draw a line between planning and execution. But for coding in an agile environment, it’s not always that obvious, especially when you’re self-taught or have an impulsive nature (which is a good thing, it just means that you really want to tackle the matter now and not later). But being ambitious about finally starting to code should never stop you from taking a deep breath and thinking it all through using the tools that help you most — even if it is just pen and paper.
