Dan's Take

Memo To Software Developers: Hurry Up and Slow Down

Too often, a 'time-to-market' mindset leads to sloppy products.

Stackify, a supplier of application performance management software, recently sent out an email blast that began with the slogan "Make it work. Make it right. Make it fast." As a reformed software engineer, this slogan caused me to stop and think a bit. (For the record, I went through a 12-step program and went from being a software engineer to being a member of product marketing and management.)

The Stackify release went on to explain that APM+ V2.3 is out, is faster and does more than previous versions. With any new version of a software product like this, how successful it will be is often dependent on the process that went into its creation.

The Production Process in 7 Steps
Most software development organizations follow a discipline that guides their initial thought through the product delivery process. Traditional processes have included the following steps:

  1. Gather data from customers and non-customers to learn what's working and not working with available products
  2. Consider where and how the organization can address the customer requirements that are the result of that processes
  3. Develop a product plan to build something customers will purchase that will address some or all of the requirements uncovered during the data gathering process. This usually includes building an acceptance test procedure that will test the resulting technology to make sure that it works, works right and will solve customers' problems.
  4. Development is started and one-to-many individual development teams work on creating the technology. This process includes creating, testing and documenting individual functions.
  5. Training for the final product is developed and the company's own support team is trained to both use and support the product. Partners' support and sales teams are often trained shortly after the internal team.
  6. As the technology gets closer to being ready for customers, selected customers and partners are allowed to try out the software. This helps the development team learn what portions of the technology are actually going to be used, find flaws in their design or coding and put the final polish on the product.
  7. If the tests are successful, the product is sent to production, the product is announced and then released to the world.

This process is exacting and, typically, a very detailed process. In the past, it often took 18 to 24 months from the initial thought to the final delivery of a product; the final product lived on the market for 3 to 5 years.

When Speed Hurts Quality
As competition made it difficult for a product to survive for a long time, developers moved to other processes. They had to use a different type of process that would let them respond quickly to customer requirements and moves made by competitors. Often these suppliers adopted approaches that could be considered "continuous development." That is, they begin to constantly work on product changes and enhancements in parallel.

The suppliers are now in such a hurry to deliver something on a regular basis that integrated, complete testing is seldom done. Customers have started to complain that software was delivered far too soon and really was a beta test. They also complain that they believed they were paying for commercial quality software, only to find out that they were being pressed into service as the final quality testers.

Dan's Take: Finding the Balance
Stackify is one supplier that seems to have found a way to balance the pressure to bring something to market quickly, while also delivering quality software that developers and administrators both like and use. They also appear to be able to compete effectively in the hotly contested APM market without losing the commitment to customer satisfaction.

What do they do that differs from everyone else? Although I'm sure that there are many little factors behind the company's success, one big on is that they've asked their development team to take the time to listen to customers, rather than only paying attention to the development schedule.

About the Author

Daniel Kusnetzky, a reformed software engineer and product manager, founded Kusnetzky Group LLC in 2006. He's literally written the book on virtualization and often comments on cloud computing, mobility and systems software. He has been a business unit manager at a hardware company and head of corporate marketing and strategy at a software company.


Subscribe on YouTube