As developers, we’ve all experienced the frustration of losing touch with the latest and greatest technologies that so captured our fascination in the first place. As we graduated from our parent’s basement to the corporate world, we found ourselves watching years breeze by as we cobbled together minor feature improvements and slapped more band-aids on code someone else wrote 3 years ago. Sure, we got to build that key feature last year, but since the rest of the product is still mired in MFC, ColdFusion, or any number of archaic technologies of your choice, you didn’t really get that same satisfaction as when get to geek out on the latest and greatest. Innovation gets relegated to little apps you write in your spare time, or not at all if you attempt to lead a life outside work that doesn’t completely revolve around computers. Inevitably, we get fed up with the hand that feeds us for stifling us, and in a way not respecting us because we know we could make things so much better if they would just give us a some leeway.
A Little Clarity
The problem isn’t unique to software development, it’s the constant struggle between art and business. You see it in every industry, but in ours it usually results in products being released to market before they’re ready, developers burnt out trying to meet market-driven deadlines and — drum-roll, please — little time to truly experiment and innovate. I’ve worked on various sizes of projects at various sizes of companies, and I’ve come to the conclusion that it really comes down to the development team manager. I’ve seen that role have many titles, but basically we’re talking about the person sitting between the developers and marketing/business-y types. True, the developer has to take the initiative to make the case for the new technology and why it’s worth looking in to, but it’s the person making the scheduling and resource decisions who can really make the difference in whether it happens or not. Managers need to get better at allocating time for such investigations. They also need to get better at making risk vs. benefit decisions when deciding to invest time in a new approach that could have long-term benefits vs sticking to the status quo which may require less effort now but cause more complications down the road. Finally, they need to be able to effectively communicate up the chain why the work should happen, or down the chain why not.
Sorry Ted, You’re One of Them Now
Having said that, developers today also need to become more business-minded. At the end of the day, it’s the financial success of the product that trumps everything else. We don’t like to hear that, but the financial success of the business is what ensures you can keep working, pay your mortgage, and buy those shiny new phones and gadgets. That means a couple of things:
Firstly, that developers who really want to build a quality product need to focus on one golden rule: build it right the first time. Any time I hear someone say “we can re-write that later” I want to wash their mouth out with soap, slap them, give them a wedgie, and then berate them with “Yo’ Mamma” jokes until they cry. Not gonna happen buddy. If a plumber said they want you to pay them to spend 3 months ripping apart your house to put in shiny new pipes with no real end benefit except the toilet will flush better, would you fork over the cash and delay having them put in the new jacuzzi, or tell them to piss off and put in the damn jacuzzi already? The same is true for developers expecting their companies to let them spend time re-writing a feature that already works because it will be “better” or “more stable”. There’s rarely a compelling business case for re-writing something that already works, so this is generally not going to be the answer for getting your techno-geek fix.
Secondly, the same is true for innovation: you need to make the business case. If you can’t do that then don’t expect your business to pay you to do it. If you truly believe that the new technology will help the product and business then work with your manager to make the case and schedule the time in.
Let’s face it, some companies just don’t have or want leading edge innovation. It’s why many developers don’t want to work for financial institutions and other verticals where they’re as likely to be running DOS apps talking to a mainframe as anything else. Other times, it’s just lack of awareness. Either way, my own personal rule for unhappiness at work is: have a plan to make things better or have a plan to get out. It’s up to you which one you pick, but I’m a big fan of speaking up and taking initiative. From experience, a lot of other people are fans too. Don’t sit around complaining and expecting other people to make things better, be part of the solution.