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.<p>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.<p>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.
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.<p>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.<p>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).<p>You can innovate on nonfunctional areas, such as devops, logging, metrics, etc, if your core business needs to be more conservative.<p>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.
<a href="http://www.infoq.com/presentations/Etsy" rel="nofollow">http://www.infoq.com/presentations/Etsy</a>
> <i>You’ll lose your best developers</i><p>So what? If you have paying customers and the software <i>"works"</i> this isn't a huge downfall. New, young and challenged developers will gladly follow in the foot steps of seasoned coders before them.<p>> <i>Recruiting will get harder</i><p>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 <i>find</i> the tools, frameworks, libraries, they need to solve that problem. They don't need this dictated to them.<p>> <i>Productivity won’t improve</i><p>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.<p>> <i>Your software will get stale</i><p>Are your customers still paying? Good, get over this aspect then. Software that doesn't change <i>always</i> goes stale.<p><i>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. </i><p>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"<p>I think this idea of innovation debt is a clear non-problem for me and most web based startups in my situation.
Related: The Dead Sea Effect
<a href="http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/" rel="nofollow">http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...</a>