Product Development: Balancing innovation with stability

If you’re staying on top of your Twitter and Facebook feeds, you’ll find a steady stream of articles about trends in technology, from large consulting firms' analysis of strategic enterprise trends to individual developers' thoughts on specific JavaScript libraries that are gaining traction. Keeping up with the new terms du jour—liquid computing, anyone?—is difficult enough, let alone understanding what the terms mean and what their impact on development will be.

Because developers love experimenting with new technology, they are often eager to try a new process or tool for the next release. Managers need to balance the risks of working with new technology against the need to get the product out. Since agile projects work in short sprints, a problematic technology can cause major issues in the release cycle.

Make sure the new technology fits your needs

Companies sometimes are afraid they'll fall behind if they don't use new tech, but following trends out of fear is a poor method for making technical decisions. All technologies in your stack, old and new, should be thoroughly researched and chosen based on the benefit they provide to the product team.

Choose new technology with an active development community

Projects that use new technology can have delays as developers get up to speed and learn the tech's finer points and gotchas. Working with open source projects is a great way to vet new technologies. There is usually a large community with forums, tutorials, and examples to help you get started with the product. Often, there's much more online support than there may be for a specific vendor implementation.

Start with a small test

Companies can also help a project succeed with new technologies by keeping familiar components in the technology stack, along with a proven process to provide a foundation for prototyping. It helps to trial the new technology in a small feature before committing to using it extensively throughout an entire project. Small tests are often the only way to verify that a new technology is compatible with the other technologies the project will use.

Commit to the project, not the technology

It's important to keep in mind that, with the exception of micro-projects designed to test out new tools, incorporating the technology is not the goal of an overall project. The team needs to be willing to cut the technology and go back to the old ways if the new way isn't working. Before you get started, identify milestones where you'll evaluate whether the technology is effective. Know how you'll assess it and have a plan for how you'll recover if it isn't.

Keep new technology in check throughout the lifecycle

The main goal of any project is to deliver the final product to your customers. Things may break while you're experimenting with new tech, but you also need to keep stable releases for early users. At the beginning of a project, there's less emphasis on writing tests and documentation, and more attention is paid to building prototypes and trying out different technologies. As the product matures, the tech stack will solidify and you start writing more tests and producing quality code with stable releases.

You should expect QA to find many more bugs during the early phases of a product. Hopefully their test plan will find the special cases that weren't covered by the requirements. Depending on the number of bugs, it may be necessary to triage and prioritize the "need to fix" versus the "nice to fix" bugs that are less important than additional features.

You can keep working towards a 100% bug-free product, but in reality, you'll never get there. Particularly when you're working on something new and innovative, with an untested market, it's better to focus on delivering your minimum loveable product, even if it isn't perfect. This lets you get feedback from early users that can shape the product in more significant, meaningful ways.

New technology has a learning curve, even after a product launch

Awareness that new technology is being used in a product shouldn't end when the last line of code is written. As IBM pointed out, there are operational impacts to using new technology. Ideally, these would be considered as part of evaluating a technology, but usually they're left to the end. Even if the technology is mastered by development, the operational team may have to become familiar with it and develop new techniques for monitoring, identifying and responding to issues, and other support tasks.

Another factor to consider is that there's no such thing as final code; it's only final until the next release comes along. That means you need to keep expertise in the new technology on your team. Cobol is far from new, and if you ask a web or mobile developer, they'd probably say it's obsolete, but Cobol is still the language behind 70% of business transactions. Before you commit to a technology, make sure you'll be able to maintain that skill on your staff—possibly for generations.

There are also plenty of new technologies that don't get beyond version 1.1. Think about what the impact would be if you need to replace a new technology that ends up not accepted in the wider community.

Be smart when making technical choices

Tech companies can't ignore technical innovation, and trends can help identify the choices to be considered, but firms need to be smart about adopting new technologies. Don't let fads drive your business decisions. Find ways to work with new technologies that support both the short and long term success of your product.