Minimizing risk in software through workflow

  • November 13, 2020

What if you could minimize the risk inherent in software development, without the need for any software skills?

Photo by Matthew Waring on Unsplash

I believe you can.

Many of the problems that I’ve seen plague new software projects usually don’t come from a lack of technical skills. Rather, the most common and costly errors stem from issues in the workflow standards in your software project.

These standards are simple to understand but require discipline to implement. They are most effective if implemented near the beginning of software development. However, they may also be adopted in long-standing projects, with greater effort.

Together, these principles can help form a guiding mindset that you and your team can adopt for your project. They won’t be perfect for every situation but are likely still helpful to consider.

Deploy Early and Often

The Days of Waterfall

In the old days, software was built like this.

The first step was to develop fully comprehensive specification documentation. You would need to create a document that would spell out every detail of how the entire system needed to function upon completion.

After developing the specification, design of the feature set would begin. Once design was compleated, development would begin, and so on.

The point is that before proceecing onto the next step, the previous one was completed in its entirely. Then it would be sent to the next team to do their work, and the next, etc.

In theory, this was to be an extremely efficent practice. In reality that’s not what usually happend. In practice, things went more like this.

The typical project was CONSTANTLY being sent back to previous steps.

This begs the question of why? More on that later, first let’s look at the effects.

One phenomenon found to be typical in most software projects is that whatever is asked to be built initially is usually not what is ultimately released. It is common for the requirements to be changed after development, especially in the development or testing phases.

In the waterfall model, every time a change needs to be made the project must return to the earlier step to make it. Then, the work of each proceeding step needs to be repeated or altered to take into account the new change.

Each time the project was passed backward, the later teams would frequently have to wait to do their work until issues from previous steps were resolved.

Because of these realities, progress down this assembly line was frequently one step forward, two steps back.

Because of this internal back-and-forth, delays started to become an industry norm. After all, how do you estimate progress when the overall project keeps getting kicked back to steps previously declared “finished?”

Photo by Rebekah Blocker on Unsplash

The second major side effect of this model is that real user feedback at scale was limited before the entire package was released. Additionally, after release feedback typically wouldn’t be able to be incorporated until the next mammoth release if at all.

This meant that the entire project was based on the original specifications – which were themselves a best-guess about what future users would want. Even if it was generated with feedback from their intended users, they wouldn’t be able to incorporate the majority of real users until the entire project was built.

The end results were that everyone waited a very long time to receive the software that frequently didn’t work as real users wished when it was finally delivered.

Photo by Sarah Kilian on Unsplash

The Advent of Agile

Over time, people began to explore alternatives to the solve-it-all-beforehand approach of Waterfall project management.

In 2001, a group of developers met to combine their ideas about how software development could be different. Out of that meeting, the Manifesto for Agile Software Development was produced and signed.

Their manifesto was simply that they value

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Deeply analyzing this document and its effects is beyond the scope of this post.

For our purposes, we’ll focus on the main idea of Agile – which is that software development should mirror the definition of the word.

Agile – according to Merriam-Webster

  1. Marked by ready ability to move with quick easy grace
  2. Having a quick resourceful and adaptable character

Photo by Alora Griffiths on Unsplash

This mindset produced the following effects

  1. Software should be delivered incrementally instead of in mega-releases.
  2. Users should begin using these smaller releases earlier. Therefore, they could start voicing their feedback while development was still ongoing.
  3. Stakeholders could react to this feedback and their own experience before exhausting the development budget.
  4. Progress in software projects became (slightly) easier to measure by management than under Waterfall.
  5. When a pivot was needed, the impact of lost work would be minimized since the work bundled in a release was smaller.

I believe that agility is one of the chiefest of virtues a new business can aspire to.

New ventures don’t have the budget to buy them time. They must react quickly to their early adopter’s feedback.

To reduce the risk in your project, strive for deployments as frequently as possible for the project.

Test All the Things

Photo by Umit Y Buz on Unsplash

As you increase your rate of deployments, your testing changes as tests need to become more both more frequent and more thorough.

How often should you test? I can only give my opinion as a veteran of software development – ALWAYS!!!

Honestly, this does show my personal philosophy in software in general; pretty much nothing can be assumed.

Others can fain functioning first, but testers finish projects fastest.

Software is commonly tested either manually, by other software, or by a mix of both.

Manual testing is generally the most expensive. In practice, manual-only testing quickly becomes no testing. Or, it becomes “the-user-does-my-testing type testing.”

Automated testing provides at least two overriding benefits.

  1. It increases the frequency of testing. This translates into a dramatic reduction of the time it takes to discover and fix bugs.
  2. It forces developers to write simpler, cleaner code as the alternative is so much harder to test. This translates into a dramatic reduction in the number of bugs even created.

I have to say that second bullet is incredibly exciting for me.

Exactly how to test and what to test are some of the most written about and hotly debated topics in the industry. If you ever wondered what keeps nerds up at night, just ask a group of software folks this question. Bring popcorn.

For the purpose of this post, let’s say your testing strategy is working for you to the degree that it provides you with the two main benefits listed above.

Involve Real Users

A common mindset amongst entrepreneurs is the thought that they need to protect their idea. What if someone steals it!?

It’s 2020 folks, and ‘ain’t nobody got time for that!

Most people already have a laundry list of projects they’d like to work on if they got the time. Real businesses take many years of time and usually prior failures.

So, if you don’t build it, it just might not get built. So, show up.

I’ve been there too many times. If you spend all your time building and polishing your idea in stealth mode, the most likely outcome is that you will one day return to the world with a new offering that no real person actually wants.

You cannot afford to trust offering’s interface solely on whatever your dev team sees fit to build, or what made sense in your head!

You need to get your idea OUTSIDE OF YOUR OWN HEAD! You’ve been warned.

One of the most effective ways of doing that is taking the most important assumptions in your idea and presenting it to a test group of your users. This can be either verbal, with a working model, or with just that little bit of functionality actually built.

Photo by Mimi Thian on Unsplash

What you have is a hypothesis about what people want, will use, and will pay for. You’d better test those assumptions before you begin dumping your years of effort and life savings onto the pyre.

Once you spend a little (limited!) time talking with real potential users, find yourself a way to test that all-important assumption – that people will pay you for this!

You can do that surprisingly easily with a few ideas from The Lean Startup. One option is instead of building a fancy whatever-it-is to do it all for you, you enroll yourself and anyone else you can convince into your very own sweatshop and do the work yourself.

Another idea is to create a page for your product with a buy button. Only, when people click explain that you’re building out the project and offer to send them email updates. Then, count the clicks and email sign-ups.

The reality is that if you can’t get people interested in your offering in these stages it won’t matter at all if you build it. You will still have to solve your marketing and sales problems.

Once you’ve validated your big idea, you should also validate your current implementation all along the way. Keep using those test groups and routinely get fresh eyes into those groups.

Even after you’ve launched your V1, this try-before-you-buy approach can keep doing you favors almost every step of the journey.


This summarizes the biggest ways I know to minimize the risk inherent to software development. This is by no means an exhaustive list, but these main points have helped many businesses large and small to take most of the mystery out of software development.

Happy coding!