Scrum is a fast moving development style. There is obviously a lot of advantage to this, but just like a sports car needs a better technical design to function at top notch, so does your code.
In this entry, we will be looking at the top three technical practices that you must adopt to ensure you are moving as fast as you could be.
Test driven development
A few days ago, our team was faced with the challenge of stress testing one of our applications. One particular use case proved particularly hard to do, the only way to run it was to literally have an actual human run through the steps!
This might be fair if we were doing UX testing, but in this case, it proved to be a big red warning sign on our architecture.
We have since worked to correct our process, but the point here is TDD helps you unravel problems before they become Problems.
By writing the test first then the code, you are forced to think through what it is you actually want to do. This makes your code clearer as well.
Not to mention, by having a “second opinion” on the validity of your code, you can deploy far faster knowing another system is checking the integrity of the entire product.
If you have ever struggled with your weight, I am certain this thought has ever come up in your mind at one point or another
Let me just eat this burger, I will work it all out later in the gym
A fantastically bad idea! Not because you will procrastinate later and not visit the gym, thou this is likely, but because you essentially threw a good chance of working towards your goal and worse compromised your future self.
In the same way, almost every day you jump into your code, you will come across an opportunity for improvement perhaps a better design pattern to adopt or even just to maximise on an opportunity to reuse code. Here you have the choice of either saying you will just do a patch now and fix it in the future or just fixing it now.
The formal term for it is refactoring and there is a wealth of knowledge out there on how to do it.
By continuously improving your code, not only will your code not rot but you will have code that gets better with age.
We all care more about what we know someone else will look at than what we are sure only our eyes will see.
The long and short of it is you want as many eyeballs on your code as possible. Obviously open sourcing your code may not be the ideal solution, but what about having your team members work on the code together?
There shouldn’t be a part fully designated to only one developer, this gives you two key advantages:
- Not everything goes to hell if the developer goes on holiday
- Everyone cleans up their code just a bit better
In 2001, Paul Graham wrote one of the most prescient essays I have ever come across, it is titled The Other Road Ahead.
One of his key arguments revolves around the fact that faster code-test-deploy cycles lead to higher quality code.
I fully agree with this argument. Continuous delivery is guaranteed to significantly reduce if not eliminate the stress which comes naturally with software development.
No longer will demo day be a day of panic. For all intents and purposes, it will just be another day in the life of the boss developer.
I hope these pointers will help you towards a better scrum experience.
Which practices here do you use in your own practice?