It’s been said that developing software is messy and it’s always messy..that’s just how it is…even with established technology and an experienced development team. But when you throw in new technology, things can even get messier because teams often are learning the technology at the same time they are building. In this case, even with the best requirements, a simple product, and the best process, things can get really messy.  In some cases, could the innovativeness of using the latest and greatest technology be harmful to the success of an organization? That notion got me thinking about how organizations can identify when innovation could be risky for the long term success of the organization.

Here are a few that I came up with:

The bus problem
…meaning there are only one or perhaps a few developers that understand an application and the technology used to build it. As a general rule…the larger, more important the system, then the more developers you need to fully understand the application and associated technology.  If you have a single even two points of failure, then you are potentially setting yourself up for future pain.  With new technology, say a new javascript framework, it may be tempting to build your new application using it…but think twice especially if you don’t have the bench to maintain it in the future.

No plan once an application goes into production
So your team has built an awesome application and released it to production.  If what happens next is the team moves onto another project without establishing a formal and agreed upon production operations plan, then you are setting yourself up for issues when something breaks…and something will break…always.  So be smart and get all the players in a room, including your operations team (if they are separate) and your security team, and agree who is going to do what.  And write it down…and not in a Word document on a common drive.  Stick it in your GitHub wiki or someplace developers actually use. Include topics like patching, monitoring, bug fixes, pager duty (do they still have pagers?).  And what happens when the product owner comes back and wants a small fix?  Production operations may very well be more difficult with new technologies.  Heck, what if that new javascript framework stops being updated?

No development standards
Do you know the technology stack your organization uses?  Are you a Java shop, .Net, strictly open source?  How about databases – mysql, postgres, oracle?  AWS, on-premise hosting, maybe a mix? Who approves the use of new technology?  How does experimenting with new technology work…does it even happen?  Are there standards for testing?  How are deployments handled…are they automated?  If the answer is “I don’t know,” then throwing new technology into the mix will undoubtedly increase risk in the long term. It’s best to have a good handle on your core technologies before you bring in anything new.

Balancing innovation, experimentation, and learning with stability and actually getting stuff done is a balancing act that organizations have to spend time thinking about.  Are you?