For those that know me personally, they will know that along with software development and writing, one of my other big passions is running. I can’t quite explain it, but every year I find myself running at least 4 or 5 marathons and often a few ultra-marathons too. This blog though is not about my love of self-torture, but rather how running a long distance has a lot in common with good software design and development.
You have to train
Almost anyone can line-up and participate in a 100m sprint race. Perhaps not quickly, but still able to cross the line regardless. The same cannot be said about running long distances where training is imperative to ensuring you are equipped to handle the mileage. And this I not just once off training, but regular and consistent training over a long period of time.
In the same way, your need to train and learn should never stop and the more you look to develop skills and acquire new knowledge the better you can adapt to the changing software development world. If you don’t train, you run the risk of becoming obsolete in the future and so it’s important both from a personal and team perspective to make the effort to train and develop often.
This can be expensive for teams as giving out money and time for resources to train is not cheap. However if you want your teams to constantly improve, they need the resources and time to be able to do so. Don’t compromise on a good training session, both in your running and in your skills development.
Start with the end in mind
When running a marathon, there is no point starting off at a full sprint and hoping you can keep it up till the end. It’s simply not possible and yet it is a mistake that many novices continue to make. Starting a marathon too quick is likely to mean you are going to be exhausted long before the end and will lead you to either having a horrible second half of your race, lead to you dropping out before the end or perhaps even getting injured. You have to start a marathon conservatively, keeping in mind that you need the extra energy for the finish.
Software design can be similar. Too often companies or teams in the hope of getting an idea out early will quickly hack something together without thinking about its future maintainability. And while this approach might make sense for prototyping, it’s not going to help you if you want to build something that needs to last. When designing your software, think about the complexities of its design and dependency and ensure it is written in a way that is easy to maintain and easy to scale without requiring rework. This is a common problem with many legacy systems that require heavy testing each time code is changed, rather than be split up into smaller services or components that can operate independently of each other.
Same applies to the testability of the design. Functionality, no matter how powerful or good looking, is useless if it can’t be easily tested. Ensuring that the tester’s needs are met in your software design not only means you will have higher quality product, but also allows you to maintain it in the future.
These things might slow you down when you initially starting writing your code and thinking about how to architecture it first, but if you get it right, your software will be able to keep going for many years rather than need a reboot or die out after a short time.
Pace Yourself
In long distance running, it’s about consistency and pacing. Speeding up and slowing down is going to tire you out more than going at a consistent pace. Finding a pace (that can be a combination of running and walking) is likely to allow you to keep going for the entire distance and often even further.
Similar to the above point, predictability is often more important in the long term than your ability to rush through release cycles. Not only does it help the team in planning and knowing they can hit deliverables regularly, it also allows you to prepare for things like quality and improved maintainability, or even if dealing with your technical debt. Don’t underestimate the predictability of your development cycle.
Refuel regularly
While you can run a short distance without the need for added hydration or nutrients, it’s difficult to maintain your energy in a long race without some form of sustenance. Now in the development world, I’m not talking about keeping your developers well fed and full of caffeine - though that certainly helps - but rather looking for ways to introspect and improve.
The truth is, humans are habitual creatures and teams can easy develop a habitual manner of working together. This can be good in fostering strong relationships, but also bad as teams can develop bad patterns and stop finding ways of improving. Bringing in a third party or allowing the team to regularly reflect on the way they work helps to rejuvenate the team and ensure they are improving rather than just functioning. It also leads to a refining of your purpose as a team, which can give them the added motivation to continue the great work they are already doing. You don’t need to do this too regularly, but at least twice a year is perhaps a good balance that allows team to innovate without sacrificing productivity.
Celebrate
I guess it should go without saying that just as you deserve to celebrate after running a long race (even if you physically cant at the time) so you should do so for your different milestones as a team. Take time to celebrate the success of your team rather than always looking to the next sprint and have fun. There is no point working hard if you can’t get enjoyment out of it and fostering a culture of fun and celebration is key to maintaining a happy team that is likely to produce great quality software together.
I’m sure there are many other traits and similarities that can be drawn out between these two, but to summarise best: what you put in is likely what you will get out. If you want to build a successful, high-quality and easy to maintain application, you and your team have to be willing to put in the hard work. If you’re just thinking of rocking up at the start line and hoping for the best, you are likely to fail and possibly never even get your project successfully off the ground.