Our happy friendly neighborhood JQuery has slowly but surely taken root in almost all aspects of the application, and it’s, well… a mess. It has grown up organically over the years, with no overall plan or architecture. The usage patterns are inconsistent throughout the app, and it’s difficult to figure out how to add new features. It feels like it’s about four years overdue for a massive overhaul. If you’re working on a large, mature project right now, this probably sounds familiar. I bet you have some similar technical debt skeletons in your code closet right now.
I can pretend that I simply don’t have the time to do that kind of forklift refactor right now, but if I am being honest, that’s not true. At the MPC our customers understand that a certain amount of time needs to go towards cleaning house. They understand that fixing this problem now means that all new feature development is going to be better for it later. They’re more than willing to make time for technical debt work alongside feature development. So, it’s not the lack of time. What is it then?
I’ve been chatting about this topic with the team lately, and these conversations have inspired me to move beyond this fear of failure. I’ve come to realize that the right direction will not simply become apparent, that “becoming apparent” actually means “iteratively trying to do something about the problem until you find the right solution”. I’ve come to realize that I just have to take it and run. Make a bad decision and fail. Heck, make five or ten bad decisions and fail five or ten times. But eventually I will get somewhere, and nine times out of ten that somewhere is a much better place than where I started. Even if I fail miserably and come out without a working product, I will have learned more than if I built two or three solutions that worked right off the bat. On top of that, the next product I build which does work will be just that much better crafted.
Going through this process, I’ve gained a better understanding of how the concepts of risk and failure relate to my job. I’ve become more comfortable with the idea that failure is normal and healthy and expected. There’s no shortage of cliche quotes about how failure is a good thing, but it’s much more concrete for me now that I can see the cost of risk avoidance and fear of failure in my project. It’s through taking risks that we uncover opportunities to improve both the code and the coder. In the absence of risk taking, we incur all sorts of costs - the cost of continuing to develop an inefficient codebase, the cost of not learning new coding skills, the cost of leaving this mess for the next developer to inherit. It certainly seems like making decisions based on fear of failure and risk avoidance end up being riskier in the end!
Stay tuned - I plan to share some more technical bits along the way. In the meantime, if you’re reading this and thinking about similar challenges in your own projects, I hope I’ve inspired you to go and find the time, space and courage to fail a little bit more. Thanks for reading!
Update: Part 2 of this series - Ember for Rails Devs: Understanding How Ember Thinks - is now posted!
Jake Wellington DevCulture