Many of us have been there, having to maintain or extend “enterprise software”, wishing we could employ some of these spanking hot, new technologies out there. We get jealous on our beard-growing, Man Bun (or Woman Bun, for that matter) wearing hipster colleagues who seem to able to use any bleeding-edge, next-gen framework out there. Sounds familiar? Awesome! That means you’re passionate about technology and craving for innovation!

In this post, I will attempt to give you some advice about how to get the innovation going in an environment which doesn’t seem to be particulary fond of it.

Fear of Change

When we suggest these shiny new opportunities to our team or manager, too often we get responses like this:

• “Things might break”

  Meaning: “We don’t have the guts to change our software”, or “Our test coverage sucks”.

• “The team might not be able to maintain it”

  Meaning: “I’m too lazy/dumb to learn new stuff”.

• “This is the way we do it at XYZ”

  Meaning: “I’m feeling threatened by change” (more on that later).

• “There is no budget for that sort of thing”

  Meaning: “We only build stuff that the customer wants”, without thinking about what’s good for the customer in the long run: giving an addict heroin might be the thing he wants, but not what’s good for him.

I’ve heard all of these respones more than once, and it makes me want to throw stuff through the office. Yes! Of course things will break, you will have to learn new stuff, and it is different from how we currently do things. But this doesn’t mean we shouldn’t do it, because:

1. Any change may break stuff, but without change there is no reward.
2. Doing new things means you have to learn things and having new experiences, which is a positive thing. Learning new things means growth.
3. “Different” might, in contrary to popular belief, be better than your current solution.
4. Using stuff that makes you happy boosts your productivity, instead of you wanting to whack something (or someone) with your keyboard. Don’t underestimate the importance of developer happiness.

Innovation means change, and most people don’t like change. People generally don’t like change because it threatens the identity they created for themselves. The threat of changing that identity instills fear, because “what will I be, without me programming C#?”. Mark Manson has an interesting take on this in his awesome book “The Subtle Art Of Not Giving A F*ck” (read it!).

Unless everyone in your team is accustomed to innovation, and thus change, there will be friction for you to deal with. Just remember: your goal is to have your colleagues accept and use your proposal, so you (at least make will have to take care of their considerations. Alienating them by bestowing stuff upon them by force isn’t going to cut it.

Getting Started

So, how do you convince your team or manager to give our innovative proposal a go? If you received one of the tragic responses above, try (a combination of) the following things:

• Talk about it, then talk about it some more. Let everyone know how piping hot the new framework is.
• Use it in some low-risk/impact application, like test- or developer tooling or a prototype.
• Find accomplices: convince people who probably are easily convinced so they can help you convince the harder-to-convince.
• Show people that you’re trying it out, host a demo or a workshop where people can try it for themselves.
• If you need approval from someone higher-up, try the bottom-up approach: get as much people around you (and around the higher-ups) enthusiastic about your idea.

Sometimes, you find yourself in a situation where you are unlikely to get permission to use that new framework. Maybe it’s time to just do what you think is best. If you’re reluctant, ask yourself: what is the worst that can happen? You’re probably not going to get fired for doing the right thing.

Innovation and Homogeneity

When you’re maintaining more than a handful of applications, homogeneity is absolutely necessary. Homogeneity allows you to understand the inner architecture of a codebase without actually drilling down into it. Applying different technology and techniques at every possibility is a threat to that homogeneity you need to efficiently maintain your platform. Innovation should add value to your technology or process, without compromising maintainability in the long run. In the short term, however, you are required to allow some diversity to grow into your platform.

For a small team with limited resources, this means you will have to alternate between creating diversity in your platform (applying new techniques) and consolidating it (applying the same to the rest), and then repeat:

Larger teams have the luxury of being able to diversify and consolidate at the same time: constantly seeking to improve our software, and at the same time striving to preserve homogeneity.

Start Tomorrow

Everything stated above is not limited to technology but can be applied to your (other) development processes as well.

What will you be trying tomorrow? Be brave, and try something new.