5 ms·

Innovation Debt

52 points by peterbell_nyc 14y ago

Innovation debt will kill your team as surely as technical debt will kill your codebase...

MattRogish 14y ago
Related: The Dead Sea Effect http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/ http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...
- peterbell_nyc 14y ago
  @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.
- slackey 14y ago
  Beat me to it!
mbesto 14y ago
> 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.
- eitally 14y ago
  This idea is not aimed at startups. It's a huge problem for large enterprises, albeit less so for product companies than for captive IT orgs creating internal systems & utilities. If you, or anyone else, would like specific examples from one company -- along with discussion of remediation attempts -- feel free to email me. When the economy went south in 2007/2008 we dismissed about 18% of our global IT org and didn't start to rebuild until late 2011. Those 3+ years of stagnation nearly killed several business critical systems.
  - mbesto 14y ago
    Fair enough -- loads of enterprise IT and IT software experience on my back... captive IT orgs creating internal systems & utilities. Again, so what? These are _costs_ centers and therefore treated as such. As long as the accounting team can add to the general ledger and the trucks ship the goods, the company doesn't go broke and people get paid. If you need innovation for your company to survive, then you do the innovator's solution - create an organisation outside the rules and realms of your existing structure to innovate. This is all too wishful and pie in the sky type thinking.
    - eitally 14y ago
      I should have been clearer: innovation debt when combined with technical debt is the issue. When the internal systems stagnate and become a) unstable, b) un-supportable, c) un-upgradable, there is a direct impact to business operations, and escaping from the cycle is time consuming and painful. I did exactly as you suggested, btw, and created a team whose explicit charter is innovation & directed R&D.
      - mbesto 14y ago
        Agreed. Feel free to get in touch if you wanna discuss further. (details in profile) I've seen this type of thing pretty much everywhere. c) un-upgradable, there is a direct impact to business operations I'd love to know how to measure this. Any VP of Tech/CIO would be fired if this happened.
ambiate 14y ago
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 14y ago
  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 14y ago
    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 14y ago
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 http://www.infoq.com/presentations/Etsy
- peterbell_nyc 14y ago
  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!

52 points by peterbell_nyc 14y ago

Innovation debt will kill your team as surely as technical debt will kill your codebase...

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

peterbell_nyc 14y ago
@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.
slackey 14y ago
Beat me to it!

mbesto 14y ago

> 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.

eitally 14y ago
This idea is not aimed at startups. It's a huge problem for large enterprises, albeit less so for product companies than for captive IT orgs creating internal systems & utilities. If you, or anyone else, would like specific examples from one company -- along with discussion of remediation attempts -- feel free to email me. When the economy went south in 2007/2008 we dismissed about 18% of our global IT org and didn't start to rebuild until late 2011. Those 3+ years of stagnation nearly killed several business critical systems.
- mbesto 14y ago
  Fair enough -- loads of enterprise IT and IT software experience on my back... captive IT orgs creating internal systems & utilities. Again, so what? These are _costs_ centers and therefore treated as such. As long as the accounting team can add to the general ledger and the trucks ship the goods, the company doesn't go broke and people get paid. If you need innovation for your company to survive, then you do the innovator's solution - create an organisation outside the rules and realms of your existing structure to innovate. This is all too wishful and pie in the sky type thinking.
  - eitally 14y ago
    I should have been clearer: innovation debt when combined with technical debt is the issue. When the internal systems stagnate and become a) unstable, b) un-supportable, c) un-upgradable, there is a direct impact to business operations, and escaping from the cycle is time consuming and painful. I did exactly as you suggested, btw, and created a team whose explicit charter is innovation & directed R&D.
    - mbesto 14y ago
      Agreed. Feel free to get in touch if you wanna discuss further. (details in profile) I've seen this type of thing pretty much everywhere. c) un-upgradable, there is a direct impact to business operations I'd love to know how to measure this. Any VP of Tech/CIO would be fired if this happened.

ambiate 14y ago

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 14y ago
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 14y ago
  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 14y ago

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 http://www.infoq.com/presentations/Etsy

peterbell_nyc 14y ago
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!