Reinventing the wheel

Right now I'm in a very familiar scene: I'm spending the weekend with my family out in the suburbs, hiding-out in my room while my mum, dad, and brother are in the lounge, shouting obscenities at the television as they watch the rugby. I'm not a very big sports fan compared to my family, so these nights all play out pretty similarly: the game starts while we're near the end of our dinner, and when we've all finished eating we clear the table and I'm left to wash the dishes while they sit down to watch the game. Often dinner was KFC, which makes my cleaning duties just that much easier, but it's not a constant of these nights of rugby.

I thought I'd be using this time to catch-up on season 3 of Game of Thrones, but this blog post has been simmering in the back of my mind for the last few months, so I thought I'd get it out of my head now.

Programmers are exposed to a lot of advice. Some of it is good, some of it isn't always applicable to their situation, and some of it can be marketing speak or complete crap - it's up to each of us, based on our own knowledge and experience, to weed the signal from the noise. Some advice holds true no matter what, and is often good advice no matter what industry you're in. "Divide and conquer" is one such piece of advice, used to tell people to break tough problems into smaller, more solvable and manageable pieces. One I've been struggling with recently is:

"Don't reinvent the wheel."

The idea behind this one is to leverage the work and experience of others who have faced similar problems to whatever ones you're facing now. In the world of programming this could mean to find if someone has made some code available for you to take advantage of so you don't have to go writing it all over again. I follow this approach quite a lot myself - especially as I find less and less time in the day to do what I really want - but I do make one exception, and that's for the code that runs this website.

At the bottom of every page on this website is a footer that says something along the lines of "Final MooCow version 8.x". Previous iterations of this site had words like "Powered by the Final MooCow". So as well as being some random name for this website, 'MooCow' is the name I've given to all the code that actually runs this website. In the beginning I used only a handful of libraries and hand-wrote(/typed) everything else. As time wore on, I surrendered more and more of my code to libraries written by others for the smaller tasks that I either found too hard to do myself, or felt I couldn't learn anything new from. The core of it however, the 'engine' I so proudly call MooCow, has been my own creation from the beginning.

But not for much longer.

There's this very mature web development framework in the Java world called Spring Web MVC - anybody who has spent any time in Java web development has heard of it, all my older co-workers have all used it in some project during their lifetime, and it's so popular that it's basically the de-facto standard for Java web development. I myself have never made use of it, but Thymeleaf has some extreme integration with it, and so many of the questions that come through the Thymeleaf forums are all Spring related that at the beginning of the year I forced myself to take a long hard look at Spring to find out what the hell it's all about.

I was expecting some kind of learning curve and maybe a stumbling block or 2 that would prevent me from unravelling this super-popular framework, but as I started reading the documentation, everything it talked about was instantly familiar to me. Why? Because everything I had done with MooCow, had been done in Spring.

The Java version of MooCow was started in 2005, so for almost 8 years I had basically been writing my own version of Spring: we use the same concepts, the same patterns, and even some of the file names we use are the same! I eventually read enough about Spring that I just threw up my hands and thought, "That's it! I'm switching to Spring."

I used the excuse that MooCow is a learning experience to keep such a tight and ego-powered grip my own code and to not making use of any other framework to replace its core. But if Spring is just doing what I did all along, then I think it's time to retire the MooCow code and let the hundreds of other developers that contribute to the Spring framework do my job for me instead. That way I can at least get some of my time back.

And this, ladies and gentlemen, is why we tell people to not reinvent the wheel.