Have you noticed something different about Iconfinder in the last few weeks? No? You weren’t supposed to. But, in fact, everything, other than what you as a user actually see, has changed. In the last month almost half of the code base running Iconfinder has been swapped out for a completely new structure in what is arguably the biggest refactor we’ve done since we switched to a brand new code base in late 2012.
The techy arguments for spending over a month on a huge rewrite are probably easy for most developers to understand: I wanted a better and cleaner code structure that was much easier to reason about, and at the same time we had some performance related issues, which needed to be addressed to keep us within the margins of what we find acceptable for performance. In other words: I wanted to get us a tiny bit closer to the pipe dream of the ideal code base. Not unreasonable, is it?
Well, two weeks into the process, our CMO, Jess, asked me over lunch what I was actually working on. “Refactoring” was my reply, naively expecting that to suffice, knowing that Jess himself is no stranger to the world of programming. It wasn’t to be. “Right, but what does that mean?” He wasn’t asking me what “refactoring” is. Rather, he was asking me what Iconfinder gets out of it. Or, in other words, he was asking me why I was wasting over a month on doing something that provided virtually zero value from, say, a marketing or business perspective.
If you’re a developer, you’ve probably heard this question before. The knee-jerk reaction is to get defensive and pull the “well, you wouldn’t understand” card. It’s easy. After all, developers do something that’s pretty easy to dismiss as “complicated,” but in reality, it’s a bull shit argument. In the world of Web software, developers are a pretty significant mainstay of the business, and we should therefore be able to argue from a business perspective about the decisions we make.
So, how do you actually justify doing something superficially pointless, like refactoring or optimizations, to the rest of your company?
From a business perspective, the obvious first argument is money. If what you’re doing saves resources or makes better use of them, chances are that the company will actually save money, as you can handle the same load with less resources. If you only have 100 users, this might not necessarily be a very good argument, but once you run 10 pretty beefy servers to keep up with the load, 10 % savings becomes real money. And, real money is hard to argue with.
This argument may seem counter-intuitive at first. But, if the work you’re doing improves performance, it’s very likely to actually improve the user experience of your product in general. A snappier product not only makes for happier users who stick around for longer, but it is oftentimes an actual differentiating factor between products.
Even more importantly though, it often has a direct effect on the company’s bottom line. Amazon has reported, that for every tenth of a second slower their site gets, they loose roughly 1 % revenue. Equally interesting statistics have come out of both Google and Microsoft’s Bing. Your milage may vary and not everyone is Amazon, but shaving half a second off of your page loads times with better code can easily translate into, well, real money.
Hopefully, us developers spend most of our time developing things that actually do shine through to the outside world. But, especially in smaller organizations like startups, where features come, change and go at a rapid rate, if you’re not careful or, hell, simply just don’t have the time, you often wind up with technical debt. That is, code which is knowingly sub-par and therefore hard or sometimes impossible to maintain.
There is a real business case to be made for getting rid of technical debt; you save time in the long run. More maintainable code means less time spent keeping existing features working and more time spent working on adding value to the business. It also means that bringing in new people to work on something gets sigificantly easier, because they neither have to spend time deciphering the existing mess nor learn all the quirks of a debt-ridden system. Instead, they can much more easily just jump right in and get real stuff done.
For the company, then, all this means that development will be sped up, sometimes drastically. Oh, and if you think of man hours as resources, this can actually be real money too – developers aren’t cheap.
It’s a better solution
In virtually all professions you get better as you work. I hardly know anyone who’s particularly pleased with work they did two years ago; they know so much more today, both about how to do things but also the problem they started solving all those years ago. Sometimes, this means that you realise down the line that your old solution for a problem simply isn’t really that good and should really be changed.
This may sometimes be hard to explain to the non-developers in your company. In that case, try to think long and hard about what not changing the solution will mean.
Find yourself struggling for arguments? Chances are you’ve fallen victim to the classic developer trap of “new and shiny.” Don’t worry, we all do it; after all, it’s part of what makes programming so damn enchanting. But, here’s the simple truth: if what you’re doing provides no actual value, chances are you shouldn’t be doing it. Simple as that. Leave it, walk away. There are more important things to do, even though they might not get your the same cred at the local meetup.
That being said, there is of course also a counter-argument to be made, that sometimes to avoid burnout, we have to have a little bit of fun and play with shiny things. But, maybe there are better places to do that than your main code base, such as having a hackathon to let off some steam.
Investing in the future
Sometimes you’ll encounter completely valid counter-arguments to what you think is the best course of action, often in the form of “but, what if you spent that time building features instead?” The thing is, that refactoring is an investment in future development. Just like a lumberjack needs to stop every now and then to sharpen his saw as it goes blunt, even if that means not sawing for a bit, we too need to maintain our tool: the code. Apple did it for Mac OS X 10.6, and now we get a new OS every year.
It doesn’t matter if you get asked
In the last 10–15 years, being a Web developer has changed from a simple profession of just making things show up to building the core part of many businesses. It’s therefore important that we embrace the business as a whole as a part of our way of thinking. This means, that it doesn’t matter if anyone actually asks the question. Instead, every time you set out to do something, make sure you spend a little time thinking about what value the work you’re about to do will actually provide.
Trust me, you’ll surprise yourself.
(oh, and a special thanks to Teodor the Cat and all his friends for their guest appearance!)