Software development process: Traps and Risks

1. What is the software development process?

Let us first set some common grounds for the keywords of this article: software, development, process, traps, and risks.

Oxford Learner’s Dictionaries defines them as follows:

Software, n. – the programs used by a computer for doing particular jobs.

Development, n. – the steady growth of something so that it becomes more advanced, stronger, etc.

Process, n. – a series of things that are done to achieve a particular result.

Trap, n. – a bad situation; an unpleasant situation from which it is hard to escape.

Risk, n. – the possibility of something bad happening at some time in the future; a situation that could be dangerous or have a bad result.

Bringing it all together, risks and traps in the software development process can be understood as: possibilities of bad situations occurring while creating or improving certain programs used by computers. It doesn’t really roll off the tongue as the title Software Development process: Risks and Traps does, but still, it’s an important definition. Nothing new there, we’re sure. But, it always helps to start at the beginning and steer our way towards our goal.

First, we’ll continue setting up our common grounds with a simplified view on any software development process. Then, we’ll jump straight into the pit of traps and risks that prey on any inattentive collaborator (e.g., developer, project manager). Lastly, we’ll bring it all home in the article’s Epilogue by providing some advice for down the road.

1.1. The basics of software development

Every project’s development is different from the rest. Even when it’s done in the same team, for the same company, and in the same domain. However, every software development goes through the same phases (from scratch to release).

We will limit those phases by reducing them to Design, Development, Documentation, and Deployment. Later, we’ll focus on the traps and risks for each one of those phases.

1.2. Design

In this context, Design is a much broader subject than just the UI part. The latter is still an important and complicated task, but we’re looking at the big picture here. We’re talking about composing the idea and drawing it out too.

Therefore, we need to take care of at least the following:

• Gather and confirm the Software Requirement Specification (abbr. SRS),
• Brainstorm estimations and confirm them too,
• Create tasks for measuring the progress,
• Design the UI and UX parts of the software,
• Decide on the software’s architecture.

After this phase, it’s time to start the Development.

1.3. Development

After everything is said and done, all contracts are signed, and Design is confirmed, we can focus on starting the development. We’re talking about more than just the team’s ability to code. There are also code repositories, automatic tests, maintenance, and many others.

Therefore, we need to take care of the following:

• Decide on a source control system (e.g., Git),
• Create certain templates (e.g., for code merge requests),
• Define code rules (e.g., strict code formats),
• Create the project and start coding,
• Set up the Continuous Integration (abbr. CI),
• Maintain the code, and keep tech debt at a minimum.

And you might ponder, what complements software the best? Well, Documentation, of course!

1.4. Documentation

Documentation is an essential part of any software project. There are many types of documentation, but there’s no such project that would explicitly require none.

Therefore, we should take care of at least the following:

• Comment your code, as the guidelines or good practices dictate,
• Write user documentation (e.g., for applications),
• Write technical documentation (e.g., for APIs).

When we’re finished with the coding part, and the documentation is ready, we’re nearly done. One could argue that there’s nothing left; however, there is still one phase left. And that is the Deployment.

1.5. Deployment

Anyone who ever installed a single piece of software had come in touch with a deployment strategy. There are many different ones; the installer is but one of many. The deployment phase should originate not in the Development but Design phase. An important factor when discussing a deployment strategy is the cost, efficiency, and, of course, any distribution limitations or demands from the client.

Therefore, we might need to take care of the following:

• Create an installer (e.g., via a script),
• Create a script to upload the built software to a server,
• Set up the Continuous Deployment method (abbr. CD, thus completing the CI/CD*).

* CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of continuous delivery and continuous deployment.

Now, we understand that one could argue that there’s even more to the software development process; and we’d agree. We intentionally simplified the process mentioned above while still providing a general idea about it.

If you would like to learn more about the software development process, you can find additional information in the following articles:

• 5 things to consider before starting software product development, and
• Software development for the pharmaceutical industry.

However, let us focus on the Traps and Risks.  

2. Traps and Risks in Software Development

2.1. Understanding traps

“It’s a trap!” exclaimed an amphibious-alien, of a space-admiral rank, in a well-known space odyssey, pointing out an otherwise-obvious situation many unfortunate space soldiers had found themselves in. Whether they were supposed to be a part of an accounted-for risk (to stay in context, collateral damage) or simply tricked adds no weight to this explanation. The fact of the matter is that their day got a lot worse because they fell into a trap. If you are not familiar with that quote, a quick web search will point you in the right direction.

Now, we can switch the context back to software development lifecycle; change the nomenclature to developers, projects, Software Development process, etc.

Any “trap” situation requires effort, time, and money to find a way out. So, since most projects are prone to traps, we best try and evade them altogether.

We can do our best to try and evade traps by understanding and identifying risks.

2.2. Understanding risks

Just for simplicity’s sake, let’s think back on the first sentence of the 2.1 Understanding Traps chapter. Before that situation had unfolded, all the space soldiers and – more importantly – their space generals were aware of certain risks that going into battle had posed. Knowing the risks, they were able to make some important decisions that prepared them best, for what followed. As a result, knowing the risks and adapting a strategy helps with the outcome of a battle.

Now, let’s switch the context back to software development; identifying, understanding, and making a risk strategy can benefit us greatly, in the long run. Doing that can help us save costs, reduce development time and in general help the team steer its proper course. We can identify risks and create strategies for them, by understanding the big picture of our projects. We must gather past experiences and think about the future for but a moment.

Risks are often countered with mitigations by creating so-called Risks and Mitigations files. They usually contain information on:

• Risk avoidance: used when a certain activity is omitted entirely due to the consequences being simply too high to justify completing it.
• Risk acceptance: acts as a counterpart to risk avoidance; it means accepting a risk for a given period.
• Risk transfer: used when a certain risk is either accepted or handled by any party.
• Risk monitoring: used when risks are being carefully monitored, and any risk changes or their impact swiftly reported.

(Source: Tech Target)

2.2.1. Risk Impact and Probability

Now that we understand the general idea of risks let us look at the standard way to estimate risk exposure. Generally, it is calculated with the help of probabilities and impacts.

Figure 1: Risk probability and impact groups (Source: Wild Card)

We can calculate the risk exposure by multiplying the probability of an event or opportunity occurring with the potential impact or damage it may cause:

Exposure = Probability x Impact

Figure 1 (above) is portraying probability and impact groups, while the Figure 2 (below) portrays a caricature of risk exposure.

Figure 2: Risk probability and impact groups (Source: Wild card)

2.3. Proactive versus reactive approach to risks

Indeed, the knowledge of the future remains a mystery. We can make assumptions, guess certain outcomes, but we can never be completely certain of what is really going to happen. At the very least, we can think of past experiences and try to come up with a strategy to deal with a possible scenario. Otherwise, luck’s all that we can count on.

A proactive approach to a Solution

Being proactive means that we prepare for certain things in advance. As we have hinted at many times throughout the article, this is one of the more important approaches to identifying risks and evading traps in a software development process.

The main part of this approach is creating a Risks and Mitigations file before any development progress starts happening.

A reactive approach to a Solution

Whenever something occurs, we’re not talking about risks anymore. Sure, it can help us identify further possible subsequent risks, but an event that has already taken place either brings us benefits or causes issues. It could, of course, not influence us at all, but let’s leave a neutral occurrence out of the discussion, as it does not help with proving any points.

2.4. Traps and risks in software development phases

Any reader should now feel comfortable enough with the words in the title of this chapter, under the context of this article. We’ve mentioned that knowing risks can help us evade traps (bad situations). So, let’s review different traps during different software development phases.

While we discuss the general idea and nature of traps and risks, you might be interested in some actual examples as well. If so, here’s an article titled Cybersecurity risks in your laboratory.

2.4.1. Design

Let’s look at some possible traps during this Software Development process phase:

• Software Requirement Specification (abbr. SRS) are incomplete, could result in team waiting for additional explanation – stuck.
• Good UI ­- terrible UX, could result in software use limitations, because only experienced users can really use it, due to a steep learning curve.
• Not optimal architecture could result in facing a deadlock: too high costs for hosting the software versus too many performance bottlenecks.

There’s a lot we don’t cover in the points above, but it should paint a picture of what can happen if we don’t think about risks. Do note that we will follow this pattern through the rest of the phases too.

Now, let us paint a picture on how those traps could’ve been avoided, if we had written a Risks and Mitigations file before starting with this phase. The file’s content would look like this:

• RISK: Software Requirement Specification (abbr. SRS) is incomplete; could result in extended development time.
  • MONITOR: Revisit the SRS multiple times, making sure that it’s as perfect as it can be.
  • MITIGATION: Include other collaborators as well (e.g., Senior engineers, UI/UX designers, etc.).
• RISK: Pretty User Interface (abbr. UI) but terrible User Experience (abbr. UX); could result in users having problems with the software, even though it’s “pretty”.
  • ACCEPTANCE: Only specialists will use the Software.
  • MITIGATION: Make sure to balance out UI and UX as much as possible; if budget allows, run A/B testing to see what works.
• RISK: Not optimal Architecture; could result in facing a lot of issues down the road due to either too high costs for running the Software or simply too many performance hits.
  • ACCEPTANCE: Senior engineers will propose an architecture.
  • MONITOR: Review the analytics.
  • MITIGATION: Always strive for maintainable and scalable systems.

2.4.2. Development

Now, let’s look at some possible traps during this Software Development process phase:

• Too much overengineering could result in longer delivery times.
• Due to missing tests every change is a breaking change.
• Not adequately following the Tech debt could result in codebase becoming one.

The Risks and Mitigations file could look a lot like this:

• RISK: Too much overengineering.
  • MONITOR: Strict code reviews and clear communication with the development team.
  • MITIGATION: make sure to catch and prevent any overengineering happening as soon as possible.
• RISK: No tests, as per client’s demand.
  • ACCEPTANCE or TRANSFER: The client expressed that writing tests are skipped for faster delivery time.
  • MITIGATION: The client will do user tests.
• RISK: Major Tech debt occurring, many junior developers.
  • MONITOR: Mandatory Senior engineer code reviewer.
  • MITIGATION: Comment on code review and manage technical debt.

2.4.3. Documentation

The documentation phase is also prone to certain traps. For example:

• Low code readability could result in slower release cycles.
• Dated technical documentation could result in many tech support emails.
• Missing user documentation could result in many user issue tickets.

The Risks and Mitigations file could’ve helped us evade the traps above. For example, the file could contain the following:

• RISK: Low code readability.
  • MONITOR: Mandatory Senior engineer code reviewer.
  • MITIGATION: Strict code reviews and code formatting rules.
• RISK: Dated technical documentation.
  • MONITOR: Mandatory Senior engineer code reviewer
  • MITIGATION: Manage API versions.
• RISK: Missing user documentation.
  • TRANSFER: The client will write the documentation and provide translations too.
  • MITIGATION: Provide enough information about the Software to the Client.

2.4.4. Deployment

Lastly, let’s look at traps during the Deployment phase:

• Developers have no optimal deployment plans (aka “Works on my machine”), which could result in several missed deadlines.
• Manual deployment issues could result in a lot of glitches and missing resources in the project.
• No Continuous Deployment (abbr. CD) setup, which could result in time wasted doing the deployments by engineers.

Once again, the Risks and Mitigations file could come to the rescue. If created, it could contain the following:

• RISK: Developers have no optimal deployment plans.
  • ACCEPTANCE: Deployment will be done by Senior engineers only.
  • MITIGATION: Create a deployment strategy.
• RISK: Manual deployment issues.
  • MONITOR: Senior engineers will report any issues.
  • MITIGATION: Learn from past issues and mistakes.
• RISK: No Continuous Deployment.
  • ACCEPTANCE: No DevOps team.
  • MITIGATION: Manual deployments.

While we have not covered every single trap or risk, there should be enough information above for any reader to grasp the idea of this topic. There is no golden hammer solution for writing Risk and Mitigation files and evading traps because they differ from project to project and team to team. Therefore, it is important to rethink them every time a new project is started and never completely let them out of your sight. Strive for Software Perfection, but understand its cost.

3. Epilogue: The long and winding road to Software Perfection

The Software Development process is so much more than just signing a deal and starting with the coding process. It requires a lot of thinking power from as diversified group of collaborators as possible. Very often, the teams working on a project can work with different technologies, use different tools, and work interdisciplinary, which by itself poses a challenge.

We’ve covered the basics of traps and risks in the Software Development process. We even went a bit further and elaborated on separate aspects of those basics. But there’s still much to learn. Stay vigilant and keep guard at risks as you steer through various phases of the software development lifecycle.

Let us finish this article with the following proverb:

… and prompt you to do the exact opposite!

Summary

As the famous proverb goes: “Give a man a fish, and you feed him for a day; teach a man to fish, and you feed him for a lifetime” the article does its best to teach about the Software Development process and the traps and risks that come with it.

First, we summarize the main aspects of the Software Development process, providing a simple big-picture view of it. Then, we focus on explaining the traps and risks and how they can manifest during the Software Development process. We elaborate on this situation by providing several examples of traps and risks, as well as providing solutions for efficiently evading traps.

The article also illustrates connections between traps and risks in the Software Development process with those in real-life situations, with the help of many popular examples, proverbs, and quotes.