“I’m going to build an app [and/or] website,” is a statement that sparks the very beginning of an exciting software journey, but few people realize the breadth of this statement when they first say the words aloud.
In a perfect world, you would have an idea, build your idea, then send your idea out into the world where millions of people would love it and buy it and there would be no problems or bugs, and you would be very successful.
If it were that easy, everyone would be doing it. The software development path isn’t quite as straightforward as that, and to best set ourselves up for success, it is important that we take time to plan for those unforeseeable speed bumps that will inevitably pop up along the way.
This article will give you insight into the logistics of the software development lifecycle, and explain why developers need extra time at the end of a project to polish things off. Finally, we will explore Codebots’ method for allocating time to accommodate this need, with the ‘trim the tail’ allocation factor.
What is the software development life cycle?
There are a variety of project management models that can be implemented to guide a software development life cycle (SDLC). Regardless of the model chosen, each has similar basic stages:
- Planning and requirement analysis;
- Designing project architecture;
- Development and programming;
- Testing; and
- Deployment.
Two of the most popular software project management methods are agile and waterfall.
In an Agile SDLC, after every development iteration, the customer is able to see a result and provide feedback. The cyclical nature of agile means requirements are not strictly defined, which can make it difficult when attempting to adequately estimate resources and development cost at the beginning of a project.
- Requirements;
- Architecture and design;
- Test and feedback; and
- Development.
The Waterfall model by contrast, is a much stricter cascade SDLC model, in which the development process is a flow that progresses you through phases of analysis, projecting, realisation, testing implementation and support.
- Requirements analysis;
- System design;
- Implementation;
- Testing;
- Deployment; and
- Maintenance.
The key difference between agile vs waterfall development methods, is that waterfall looks at software development as a linear sequence of events, while agile is based on continuous iterations of development and testing.
Agile is Codebots’ method of choice, as it fits hand-in-hand with our commitment to continuous modernisation.
On your software development journey, there will be frequent periods of exploration and discovery. Some requirements may change, some may become obsolete. Taking a step back and reflecting on the work you have completed helps you adequately assess the areas that need your attention. Failing to do so can increase the impact of software risks. This is why developers need extra time at the end of a software project to polish things off - so they can fix minor bugs that hadn’t been major priorities, address any technical debt they’ve incurred, and implement minor improvements that have resulted from user feedback - to provide customers with the best possible solution for their business.
At Codebots, we use our allocation factor to ensure we have adequate time set aside for this essential polishing, to reduce the impact of potential software risk. We call it the ‘trim the tail’ factor, and we’ll dive deeper into how it works later in this article.
What is software risk?
Software risk refers to anything that can affect a project’s timeline, budget, or use, which includes the development of poor quality software. Risks exist because the future is uncertain, especially when you are at the beginning of your software development journey.
Imagine that building software is like climbing a mountain. You may have an idea of how steep the mountain is, and what equipment you will need to successfully climb it, but many factors will be unknown and circumstantial. You won’t know if the weather has impacted climbing conditions, how many other people are also climbing the mountain, or how their actions will affect your journey. Perhaps your path will be blocked by fallen rocks, and you must choose an alternative route to the top.
Regardless of how much you plan, there are many known and unknown aspects that cannot be completely addressed in your initial project plan.
Risks can be either internal, within the control of project management, or external, beyond the control of project management. We can typify risk by how much information we have about them; known knowns, known unknowns, and unknown unknowns.
Known knowns are factual risks all stakeholders are aware of, for example, you may know that you need a certain number of developers for your project, and if you don’t have enough developers, the project timeline will experience a delivery delay.
Known unknowns are risks that project teams are aware of, but are unaware if such risks will exist in a particular project or not. Communication is a good example of this, i.e. if communication with a product owner is not strong, it may not be possible to adequately capture project requirements.
Unknown unknowns are risks that commonly occur when customers request you work in a certain way or with certain technologies you are unfamiliar with, which exposes you to unforeseeable risks.
What is the impact of software risk?
Assuring the quality of software is an ongoing challenge in a world of continuous modernisation. Additional breakdowns can occur if development specifications are not rigorously documented, if developer experience and skill sets are not validated, or if procedures or security measures are not strict.
Outsourced application development services can expose enterprises to an array of risks, for which enterprises remain accountable. Such risks include backdoors, data corruption and privacy, poor code quality and viruses. This is why it is crucial to not just ensure you manage risk, but that you trust the risk management systems any external vendors you work with.
Imagine you were working on a customer project, and a developer on your team was using an unapproved third-party vendor to monitor their code quality. Then imagine that third-party vendor extracted all your customer’s confidential data, and sold it to a competitor. This would have a catastrophic impact on both your customer’s business, and your business’ reputation.
How do we manage software risk?
Alleviating risk is much easier if you have a risk management plan in place. In basic risk management, you may take steps to identify a risk, reduce the potential impact and probability or likelihood, then monitor the risk to ensure you maintain control. The following steps will guide you to better manage software risk.
1. Risk identification.
When you have a clear understanding of a project’s requirements, you can commence risk identification. You should identify both the project and product risk by reflecting on issues that arose in previous projects with similar requirements, and having an open discussion with all stakeholders.
By studying problems you faced on previous projects, you can better assess all the possible areas that are vulnerable to risk. Creating a flowchart can be an effective way of analysing a project plan, enabling you to identify known unknowns you hadn’t considered before looking at a visual plan. Any decision that has a potential impact on technical, operational, political, legal, social or internal or external factors should be evaluated extensively.
2. Risk analysis.
Once you have identified all the known risks and known unknowns, you can assign a risk rating to each potential risk. A good way to categorise and order them is by determining the likelihood and potential impact of each risk. Likelihood should be defied by a percentage, and based on various technical conditions, including:
- The complexity of the technology;
- The technical knowledge of the testing team;
- If there are any conflicts within the team;
- If teams work in house or remote; and
- The quality of testing tools that will be used.
Some important questions that help determine the impact of a risk include:
- What will be the loss to the customer?
- How would their / our business suffer?
- Would there be a loss of reputation, or harm to society?
- What are the potential monetary losses?
- Could legal action be taken against the company?
- Could risk result in cancellation of business licenses?
Don’t forget to give yourself some leeway for those pesky unknown unknowns!
3.Risk mitigation / risk control.
After you have an idea of how potential risks may affect a project, it is important to create a mitigation or contingency plan that addresses each point. Risk mitigation may prompt you to reevaluate how policies, procedures, and technology are used within your company, enabling you to be better equipped to handle risk in general, particularly with regard to security risks that may arise from things like shadow IT.
Codebots manages software risk with our ‘trim the tail’ allocation factor.
The ‘trim the tail’ allocation factor is Codebots’ method for calculating a period of time which can be drawn from at any point in a project’s timeline to polish software and alleviate or minimise risk.
Our software development experience has shown us that every project requires periods of cleaning up time, where teams can pause on active development and focus on the work they have already done. The bank of time added into a project with trim the tail enables teams to account for any bugs or minor improvements that may pop up along the development journey.
Since the trim the tail factor is accounted for in the planning stage, it can be drawn upon at any point in a project’s timeline, usually when the squad lead and project manager agree it is required. In this instance, development is paused and teams move into ‘iteration N’, which varies in length depending on the amount of work required. Teams can enter into several ‘trim the tail’ iterations chipping away from the total allocated time for polishing.
Based on our experience, we calculate trim the tail as a 1.25 multiplier on the time estimate.
Written by Eban Escott
Founder of Codebots
Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.
