Pete “Maverick” Mitchell’s famous words in the blockbuster Top Gun, “I feel the need, the need for speed,” somehow has found resonance with product owners in the dynamic world of software product development. A rapidly evolving market and technology landscape driven by changing customer demands are compelling software development companies to get products out faster than the speed of light. As most organizations put the pedal to the metal to accelerate time-to-market, it is crucial to remember that this need for speed can be a very costly mistake, especially when it comes to the cost of software quality.
Here are a few deadly sins (I’ll not call them mistakes considering the competitive fallout and the reversal of software development’s progress) that every organization looking to develop software products must avoid.
Cutting corners
What is the most obvious strategy that companies adopt when they want to release faster? You cut corners.
This strategy is sacrilege in a world where the end-user has no sympathy for slow, bug-prone, and low-quality products. Low code quality can severely impact software performance and can create some significant hurdles during product evolution.
Mapping out the entire product idea to create a workable product vision can help determine which features are essential now vs. next release. Understanding user needs, the problems the product will have to solve, evaluating the landscape, and understanding the user are necessary for creating a robust product with the essential elements that can make a differentiated design experience.
Prioritizing and planning thus become essential to create a robust product and development roadmap. Conclusion This approach is critical to ensure that cutting corners is limited and eliminating shortcuts that negatively impact its development process.
Not testing judiciously
Inadequate or insufficient testing is another cardinal sin committed to releasing a product fast. While testing can be a time-consuming process, it is ‘the’ process that will determine whether your product will be accepted or rejected.
The cost of fixing bugs is exponentially higher when discovered in the maintenance phase. So, instead of ignoring testing or testing less, it makes sense to increase testing speed to match the development pace. It is essential to have a robust test automation plan.
However, automation has to complement manual testing, especially as focus on usability and security increases. Software development organizations have to make sure they can bake protocols such as product license agreements that include compliance certificates with the top SANS 20 security controls and the like in their testing suites. Since these tests are not automation inclined, you need testers with expansive knowledge, strong testing skills, and deep insights into the security protocols to ensure that the security aspect is expansively covered. UI and UX testing and exploratory need focused manual testing on passing the human test and ensuring product acceptance.
Accumulating technical debt
Yes, a certain amount of technical debt is not only unavoidable but, in fact, necessary to release products faster. However, just like in financial debt, it makes sense to accumulate only as much debt as you can pay off quickly. Adopting sub-optimal coding practices to deliver software faster and leaving the code’s cleaning up later builds up technical debt. The more the technical debt, the harder it becomes to implement changes to the product later.
Technical debt will also impact software performance, make it less stable, and more open to vulnerabilities. Keeping technical debt under check is essential even if it means that you have to slow down for a little while since fixing technical debt later will cost you money, human resources, and quite probably your customers.
Remaining hyper-focused on testing, keeping a keen eye on code smells, measuring technical debt proactively, avoiding source code complexity, and having a roadmap to resolve and pay back the technical debt are essential before releasing a product.
Ignoring refactoring in product evolution
Organizations using Agile and DevOps as development methodologies have to focus on refactoring to avoid code rot. Code rot creates an unhealthy set of dependencies between packages and classes, leads to low allocation of class responsibilities, and generates spaghetti code. All of these contribute to technical debt, something that we have to control.
Since Agile and DevOps maintain and extend their code from iteration to iteration, refactoring ensures that the code base is not shaky and unadaptable to product evolution. Implementing minor refactoring as a best practice and refactoring focus might make it seem like sprints are falling behind, but this is the best example of “sometimes you need to slow down to move faster.”
Refactoring ensures that developers are always aware of the code, its quality, and its problems and can proactively develop the plan to address these issues to ensure quality and code throughput.
Not paying attention to the software delivery process.
Organizations wanting to accelerate their release frequencies are, like Freddie Mercury, singing, “I want it all; I want it all now.” However, it is essential to be heavily process-oriented and have a well-defined and streamlined software release process. And along with tools and technologies, this process must ensure a working alignment of the business strategy with customer needs. Following software development methodologies such as DevOps and Agile makes this more comfortable and helps organizations release quality products that will see greater user acceptance.
Finally, we need to accept that software development has now reached an inflection point. Today, the idea of the perfect release is obsolete. What matters more are the processes that enable faster turnaround, better usability, more stable code, and overall development efficiency. Until you’ve got those right, don’t think about releasing.
You can also read this article on Medium.com
Pete “Maverick” Mitchell’s famous words in the blockbuster Top Gun, “I feel the need, the need for speed,” somehow has found resonance with product owners in the dynamic world of software product development. A rapidly evolving market and technology landscape driven by changing customer demands are compelling software development companies to get products out faster than the speed of light. As most organizations put the pedal to the metal to accelerate time-to-market, it is crucial to remember that this need for speed can be a very costly mistake, especially when it comes to the cost of software quality.
Here are a few deadly sins (I’ll not call them mistakes considering the competitive fallout and the reversal of software development’s progress) that every organization looking to develop software products must avoid.
Cutting corners
What is the most obvious strategy that companies adopt when they want to release faster? You cut corners.
This strategy is sacrilege in a world where the end-user has no sympathy for slow, bug-prone, and low-quality products. Low code quality can severely impact software performance and can create some significant hurdles during product evolution.
Mapping out the entire product idea to create a workable product vision can help determine which features are essential now vs. next release. Understanding user needs, the problems the product will have to solve, evaluating the landscape, and understanding the user are necessary for creating a robust product with the essential elements that can make a differentiated design experience.
Prioritizing and planning thus become essential to create a robust product and development roadmap. Conclusion This approach is critical to ensure that cutting corners is limited and eliminating shortcuts that negatively impact its development process.
Not testing judiciously
Inadequate or insufficient testing is another cardinal sin committed to releasing a product fast. While testing can be a time-consuming process, it is ‘the’ process that will determine whether your product will be accepted or rejected.
The cost of fixing bugs is exponentially higher when discovered in the maintenance phase. So, instead of ignoring testing or testing less, it makes sense to increase testing speed to match the development pace. It is essential to have a robust test automation plan.
However, automation has to complement manual testing, especially as focus on usability and security increases. Software development organizations have to make sure they can bake protocols such as product license agreements that include compliance certificates with the top SANS 20 security controls and the like in their testing suites. Since these tests are not automation inclined, you need testers with expansive knowledge, strong testing skills, and deep insights into the security protocols to ensure that the security aspect is expansively covered. UI and UX testing and exploratory need focused manual testing on passing the human test and ensuring product acceptance.
Accumulating technical debt
Yes, a certain amount of technical debt is not only unavoidable but, in fact, necessary to release products faster. However, just like in financial debt, it makes sense to accumulate only as much debt as you can pay off quickly. Adopting sub-optimal coding practices to deliver software faster and leaving the code’s cleaning up later builds up technical debt. The more the technical debt, the harder it becomes to implement changes to the product later.
Technical debt will also impact software performance, make it less stable, and more open to vulnerabilities. Keeping technical debt under check is essential even if it means that you have to slow down for a little while since fixing technical debt later will cost you money, human resources, and quite probably your customers.
Remaining hyper-focused on testing, keeping a keen eye on code smells, measuring technical debt proactively, avoiding source code complexity, and having a roadmap to resolve and pay back the technical debt are essential before releasing a product.
Ignoring refactoring in product evolution
Organizations using Agile and DevOps as development methodologies have to focus on refactoring to avoid code rot. Code rot creates an unhealthy set of dependencies between packages and classes, leads to low allocation of class responsibilities, and generates spaghetti code. All of these contribute to technical debt, something that we have to control.
Since Agile and DevOps maintain and extend their code from iteration to iteration, refactoring ensures that the code base is not shaky and unadaptable to product evolution. Implementing minor refactoring as a best practice and refactoring focus might make it seem like sprints are falling behind, but this is the best example of “sometimes you need to slow down to move faster.”
Refactoring ensures that developers are always aware of the code, its quality, and its problems and can proactively develop the plan to address these issues to ensure quality and code throughput.
Not paying attention to the software delivery process.
Organizations wanting to accelerate their release frequencies are, like Freddie Mercury, singing, “I want it all; I want it all now.” However, it is essential to be heavily process-oriented and have a well-defined and streamlined software release process. And along with tools and technologies, this process must ensure a working alignment of the business strategy with customer needs. Following software development methodologies such as DevOps and Agile makes this more comfortable and helps organizations release quality products that will see greater user acceptance.
Finally, we need to accept that software development has now reached an inflection point. Today, the idea of the perfect release is obsolete. What matters more are the processes that enable faster turnaround, better usability, more stable code, and overall development efficiency. Until you’ve got those right, don’t think about releasing.
You can also read this article on Medium.com
