When creating software, innovation is often taken for granted as a desirable objective and mentality. Looking at it more closely, there are entire classes of software systems for which innovation is actually not in the discussion. In 2020 you rarely see a COBOL, Ada, Fortran, or Delphi developer position advertised as an opportunity to innovate. This is because any attempt to fundamentally change an old enough software system has a good chance of exposing software rot, so it’s best for all parties involved to not try.
However, “Legacy systems are not innovative!” is not breaking news, and it’s also not the point of this post. The point is that almost everyone talks about innovative software, but not everyone means the same thing. My hypothesis is that there are several types of software-centered innovation.
I propose the term fast innovation to identify the currently prevailing practices of consumer-facing software companies, and especially startups. This is a set of practices loosely aligned with the famous “move fast and break things” motto formerly employed by Facebook:
- The single most important activity is gathering feedback as fast as possible;
- The second most important activity is generating ideas and features on which to gather said feedback;
- Introducing bugs is not catastrophic because a fast release cycle mitigates their effects;
- Setting and meeting deadlines is not seen as a productivity driver;
- Some things don’t matter at all, such as avoiding the deployment of hidden features – doing so is actually useful for A/B testing.
This philosophy has different incarnations, notably the Spotify Squad framework and a very large palette of Agile methodologies (The Agile Manifesto in fact predates the Facebook motto by several years). Nowadays most organizations that produce software attempt to adopt or adapt one of these processes. Sadly, some end up with a very expensive Agile cargo cult.
Another type of useful and legitimate information is slow innovation. This term applies when software is used to solve hard but at the same time well defined problems, often in conjunction with some type of research or standardization effort.
For example, a company contributing to a hypothetical new version of the Geography Markup Language then implementing it would be right to see itself as an innovative organization, even though the entire process of delivering the new features will have taken years. Most levels of safety-critical software also fit in this category because of the extensive testing and certification which all but prevents moving fast.
The following are some examples practices aligned with slow innovation:
- Extensive (but not unlimited) time is allocated to research with no immediate measure of success;
- It’s important or even critical to avoid introducing bugs;
- Project deadlines are important in order to align with validation and certification timelines, and also because this type of work often follows a business-to-business sales model;
- The feedback loop between generating and validating an idea can be long, and it’s not always feasible to shorten it;
- Aspects such as hidden features and A/B testing can violate regulations, and may be avoided entirely.
You should know which type of innovation you are aiming for
When picking or creating a software development process and culture for your organization, a wise first step is to identify as precisely as possible which type of innovation your business is engaged in: fast innovation, slow innovation, or no innovation. In case you are somewhere in between, try to identify which parts of the mentality and processes you want to adopt from the communities and trend-setters in each of these categories.