Planning things out before you start
One thing we really try to do at Our Very Own is planning. Before we start any major piece of work or any piece of work at all other than a very small feature, we sit down and plan out what it is we need to achieve and how we are going to do it. The act of planning out a feature has become extremely beneficial in my opinion. It allows you to go through the process of planning out the requirements, looking at the current implementation, if there is one, researching the tradeoffs of each approach and finally it gives you a chance to show other people. Showing other people what your thinking before you do it, is more important than one might think. Showing someone else gives you that sanity check, it allows someone else to come in, understand what you're doing and point out things that you might have missed or tell you what your doing is mental please try again. Which is okay because you haven’t written any code so it's quite easy to start again.
I recently had to implement a payment system using Stripe, which was much harder than I originally thought, and I knew that it wasn’t going to be straightforward when I started. We use Confluence to create wiki pages in order to plan out our features, not only do they act as a plan for others to see, they also act as documentation beyond what is in the tests and in the code. I spent about a week planning, weighing the various payment vendors, how we were going to roll it out, what the requirements were, if we needed all the features in for day one. Then once I was finished I was able to show the whole team, they could read over it, discuss it with themselves and most importantly raise any issues they had with it. Beyond just the issues, they also raised additional problems I might not have thought about or better ways to sort problems. This collaboration was fantastic, it meant that I covered all bases, thought of all possible problems and most important, the feature was documented so that people in the future could know the thinking behind why we did what we did and how it worked.
This documentation lives in a hosted central place where anyone in the team can log in and find the plan for the payment feature. Furthermore, it makes it much easier for people in the future to make changes because they know how it works and why it works that way. They can look at the features of that system and add new ones by following the process that was already laid out. One of the little known benefits of planning is that when it comes time for someone to review your pull request, they have some additional material to explain the thought process behind your design decisions. It makes it easier to check the features of the code to the features of the plan, making sure they’re all there and working as they were planned too. How many times do you go to review someone's pull request only to become lost just trying to understand what they have done? Well you might still get lost, but at least you have some plain english to look over before you jump into someone else’s code.
Planning takes time, a lot of time, you sit there and think about a lot of things. You do a lot of research and that entire time you write zero lines of code! This feels the same as an alcoholic not drinking for a week, god damn terrible! Yet it’s a must and I would argue that it’s a much better way to spend your time than to jump straight into code. It forces you to slow down, to think about the problem, to find gaps in the feature requirements and the feature description. You become forced to think about why your doing this in the first place, beyond the “I was assigned this stupid card”. It gives you time to think about why this feature is beneficial to your customer, how to make it as easy as possible to roll over with as little down time as possible if any. It allows you to ask questions which is extremely important especially when the features have been written by someone who has no experience with development. They could be asking for something that just isn’t possible, but you might not know that till you either get really deep into the code or you spend a day planning it out. In which you find out that the feature they want actually can’t be built in the system because that's not how the system works. This saves you a tonne of time in the long run.
I’ve written all this and I’ve still yet to talk about the most important thing! Planning out what your going to do produces much less error prone code. It’s simple the longer you spend thinking about the problem, the tradeoffs, the inevitable limitations and you discuss it with others. The better your code becomes and the better the product becomes. You also spend much less time fixing bugs or adding additions to the feature because you left something out.
There have been many times where I’ve spent days creating a feature only to push it into develop and find out that I’ve missed some key functionality that the frontend needs but no one else realised because I never showed a frontender the plan, I didn’t show anyone the plan, because there wasn’t one. The times I have planned, such as the payment feature, it has taken longer yes, but the quality of the feature and the smoothness of the rollover have been much easier.
Producing high quality code is vital. It creates a better product, less bugs and easy to maintain code. All these things are possible without a plan but you’re going to have a bloody hard time doing it. The more you plan the easier time you will have when it comes to implementation and maintainability. You will spend less time fixing your terrible code and more time looking like a brilliant programmer.