

Innovation Debt - peterbell_nyc
http://blog.pbell.com/2013/03/19/innovation-debt/
Innovation debt will kill your team as surely as technical debt will kill your codebase...
======
ambiate
I'm currently working at a company that is facing this problem. The
programming team has stagnated on repairing legacy systems. Innovation and
modernization is a business objective, but the philosophical issue of losing
'expert business knowledge' due to technological evolution presents barriers
in the process.

Our code ranges from 10 to 20 years old. Most of the principles involved in
that based are from those years too. Moving to any framework, language or SOA
means training 16 people for years. Not because the language, framework, or
services are too hard to grasp, but because the overall arching backbone is
missing. We haven't reached 3-layered programming, let's jump straight into
5-layered.

We're still in waterfall functional code with weak modularization and few OOP
principles. Yet, we're trying to skip the whole OOP/modularization schematic
and jump right into fully decoupled SOA. Without understanding the hardships
of the middle, I find it difficult to believe we can transition to the end
without losing half of our team.

~~~
peterbell_nyc
Yeah - that's a really hard change. For anyone dealing with a legacy system, I
always recommend Mike Feathers' book on "working effectively with legacy
code". He talks about lots of patterns for dealing with this.

I'd probably see if I could start to break off a piece of a system, bring in a
consultant or new dev for a couple of months, pair them with one of your team
and rotate every few weeks. You won't lose too much capacity in terms of
working on the core system and you'll get a chance to start to slowly
introduce members of your team to new best practices. Sometimes single page
web apps can help with some of this as you can just drop in backbone on a page
or two and use it to federate data from both your main app and a new app
you're adding some functionality to.

You probably will end up losing half the team over time, but honestly if they
put up with the current state of affairs for so long, that might not end up
being a bad long term outcome. Just don't big bang any changes - cultural or
technical. And try to ignite curiosity rather than "mandating innovation"

~~~
ambiate
Thank you for the advice and reference. It is difficult to find actual advice
in these circumstances other than 'consult consult consult.'

That last line really shifted my outlook on this experience.

------
jbarmash
Another way to keep sharp, which surely Peter knows (as he runs several
meetups in NYC), is to encourage your team to get involved with local meetups,
both as an attendee and a presenter, or do other community-oriented stuff like
teaching classes (e.g. skillshare). This has two positive effects – increases
the flow of new ideas, and (when speaking) helps your company / team to get
more visibility in the community.

While I am very supportive of learning and using cutting edge technologies
when it makes sense, it does need to balanced with technical risk assessment,
which your post alludes to at the end. For example, say you want to try the
Rust language and think it would give you some advantage. Things like maturity
/ community, etc, definitely come into play.

Innovation comes not just from using new technologies, but also from using new
techniques with old boring technologies. I’d even argue that working on
cutting-edge problems forces you to innovate, alleviating some of the
innovation debt issue (not everybody has that issue).

You can innovate on nonfunctional areas, such as devops, logging, metrics,
etc, if your core business needs to be more conservative.

One of the best talks I went to in the last year was by CTO of Etsy, where he
talked about how they use “the most boring technologies they can find” – php,
mysql, etc. At the same time, Etsy has a very strong reputation in the tech
community. <http://www.infoq.com/presentations/Etsy>

~~~
peterbell_nyc
Hi Jean,

Agreed 100% - both with the value of meetups and balancing the technical risk
assessment. I'm doing a keynote at NFJS New York on "how to select and adopt
technologies" that talks a lot about community focus, where in the technology
adoption lifecycle the technology is, etc.

You also have to look out for how many technologies you're managing. I'm a fan
of polyglot programming and polyglot persistence, but that doesn't mean you
should have five server side languages and seven different NoSQL data stores.

Agreed re: innovating on peripheral apps. Only thing I'd add is select
technologies that _could_ be great for your core, innovate peripherally, and
once you have some experience you can revisit the risks of introducing that
tech into your core stack.

Nice link re: the infoQ etsy talk - thanks!

------
mbesto
> _You’ll lose your best developers_

So what? If you have paying customers and the software _"works"_ this isn't a
huge downfall. New, young and challenged developers will gladly follow in the
foot steps of seasoned coders before them.

> _Recruiting will get harder_

This is a problem for every company with developers. As long as you have
paying customers, recruiting isn't as big of a problem as people make it out
to be. Is this a problem for places like Google and Facebook? Sure. For you
start-up, probably not. Software challenges tend to trail off towards the
latter part of the software's life cycle. If there is a new piece of
functionality required then smart developers will simply _find_ the tools,
frameworks, libraries, they need to solve that problem. They don't need this
dictated to them.

> _Productivity won’t improve_

You also are inherently decreasing their productivity by teasing them with new
technologies that may never be used. You can also clearly quantify their loss
in productivity when they spend time on new technologies. I'd prefer to
measure the measurable and manage that, rather than half guess a "innovation
debt" that I'll never be able to manage properly.

> _Your software will get stale_

Are your customers still paying? Good, get over this aspect then. Software
that doesn't change _always_ goes stale.

 _It happens when the team is too busy putting out fires and finishing up
features to keep up to date with advances in languages, frameworks, libraries,
tools and processes._

What about the increased costs (real actual currency HR costs) that are
included in constantly taking your resources off the software maintenance and
delivery for a product/service that real people are paying for. There are some
serious implications with letting people's innovative brains wander too far
when given a specific task to accomplish. This is why hackathons and "FedEx"
days are so popular. It's a mutual agreement between employer and employee
that says: "You are allowed to hack something together with new exciting
technology but I cannot guarantee it will reach the production stack"

I think this idea of innovation debt is a clear non-problem for me and most
web based startups in my situation.

~~~
setrofim_
This is a very short-sighted view. While losing great devs will not put your
company out of business over night, it may start a death spiral that it will
be very difficult, if not impossible, to recover from. Hiring may be easy for
you now, but once your start up starts falling behind the curve, if will
suddenly look a lot less attractive to new talent.

> If there is a new piece of functionality required then smart developers will
> simply find the tools, frameworks, libraries, they need to solve that
> problem. They don't need this dictated to them.

What smart developers? They have all left to work for your competitor. Besides
finding the right tools, frameworks, etc takes time, which is precisely what
this article is arguing for.

> Are your customers still paying? Good, get over this aspect then

Your customers will stop paying when something better comes along. And it will
come along because, unlike your company, others are innovating.

> You also are inherently decreasing their productivity by teasing them with
> new technologies that may never be used.

Maybe, but not by as much as you'd think. Looking into new technologies may
often improve productivity with the technology currently being used (by
bringing in ideas from the new tech).

> What about the increased costs (real actual currency HR costs) that are
> included in constantly taking your resources off the software maintenance

You don't have to constantly take resources off. Just occasionally. A day-long
hackathon a year, and a couple of lunchtime sessions a moth is really not that
much.

> I think this idea of innovation debt is a clear non-problem for me and most
> web based startups in my situation.

The thing about innovation dept, like architectural debt, is that it doesn't
become a problem until it is too late to do something about it.

~~~
mbesto
_The thing about innovation dept, like architectural debt, is that it doesn't
become a problem until it is too late to do something about it._

And do you believe this is seriously something that is killing companies left
and right?

You know what kills companies? Cashflow.

~~~
OldSchool
I certainly lean heavily in the direction you describe; cashflow or better
still, net profit is the lifeblood of any real business.

So if you're barely staying alive, anything that doesn't soon lead to revenue
and acceptable gross profit is a luxury you can't afford.

On the other hand, if you are an owner with a steady profit-generating machine
you want to keep it running as smoothly as possible as long as possible.
Investing a relatively small amount directly in your employees' professional
development is a way to help this happen.

Employees like to stay current and feel like you care enough to keep them
current. Going from spending $0/yr on someone for training to $1000/yr will
probably make them a lot happier than a $1000/yr raise. That might be as
simple as giving a group a collective budget for books and courses on anything
related to your business.

There is a definite cost when a core member of your team, no matter which
level, moves on due to boredom. This is one way to keep them a little happier.
Some aspects will show up in your company's resources beyond just happier
employees too.

------
MattRogish
Related: The Dead Sea Effect [http://brucefwebster.com/2008/04/11/the-wetware-
crisis-the-d...](http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-
dead-sea-effect/)

~~~
peterbell_nyc
@Matt, thanks for including this link. I'd read it a while back (maybe a link
from you!) but couldn't find it when I was putting this together last night.

