How Software is Made in 2022

(For Non-Technical People)

Software development can be an incredibly mysterious and frustrating process...not only for the developers making it, but also the end users who use it.

My goal today is to explain the two most common ways that we build software, and why one of them is terrible and the other is fantastic.

Broadly, there are only two “main” methods to building software:

1. Waterfall (“Old”)
2. Agile (“New”)

If you have ever heard of “SCRUM” or possibly “Extreme Programming”…those are just “specific versions” of these. I won’t even bother discussing these, because no one follows them 100% verbatim anyway; every company has their own “special” methodology.

Waterfall

Waterfall first came into being in the 70’s. On paper, it looks great. You start on Stage 1 (Requirements Gathering) and end on Stage 5 (Deploy). You have a set timeline, and you are not allowed to go backwards.

Waterfall is great for projects where you know exactly what you need to build. In other words…..not software :)

Agile

In the early 2000’s, Agile came along. Agile essentially has the same 5 stages as Waterfall, but you cycle through those stages several times. It doesn’t look as good on paper…but it produces better results in the end.

For this reason, Agile has largely obsoleted Waterfall in the industry. There will always be those few cases where waterfall is the better method, but the industry overall prefers Agile.

In summary….both methods essentially follow the same steps. But with Agile, you iterate on those steps several times.

The Steps

1. Requirements Gathering — These are typically meetings. You meet the end users, learn about their problems, draw diagrams of how you think the application should work, diagrams of the business process, prioritize features, commit to a basic timeline, etc.
2. Design — This almost always includes a “wireframe”, which is a black and white outline with boxes and arrows of the main pages and features. For visual-heavy projects, such as a website, you may also have a “mockup”, which is a colorful sketch of how the site/app will look. Finally, for functionality-heavy projects, such as a manufacturing application , you may have a “prototype” which is a very basic, but working, version of your application that the users can actually click around in.
3. Develop — This is where the majority of the “coding” happens. This is best accomplished with tons of caffeine and minimal background noise. This may involve light testing as well (“pretending” to be a user…just to make sure all of our buttons and dialogs are working correctly).
4. Test — This is where we have the users sit down and try out the software. If you are following Waterfall, you are praying to God that your application is close to what they expected….because if it isn’t, you have a very limited amount of time to get it “corrected”. If you are following Agile, you are expecting and WELCOMING feedback on where you are going wrong.
5. Deploy — This is where “everyone” starts using the software…and it is considered “done”.

My Favorite Methodology

Most companies will have their own “special” process, which is usually some combination of Waterfall and Agile.

Agile works best when you don’t understand the problem 100%, and in my opinion, that is the case with most software projects. (We all THINK we understand it….but if users can’t use the software or the problem remains unsolved, you didn’t ACTUALLY understand it).

With Agile, you deliver a prototype very, very early in the process. What I LOVE about this is….it gives you, your users, and even your managers something to FOCUS on. Instead of talking past each other, you now have something specific you can point at and say “Is this what you mean?” or “This is what I am working on right now”.

It also lets you build a ubiquitous language. Unsurprisingly, your programming terminology sounds like an entirely different language than their business terminology. As we work with users, we learn what they MEAN when they speak (not what we THINK they mean). They also learn some of our programming words.

For example: when I first meet users, and they ask for features, they tend to just call everything a “tab”. “I need a tab for this, I need a tab for that”. I force them to use more descriptive words like “button”, “dialog” and “dropdown at first.

As we work together, we build a common language that lets us communicate effectively.

Finally, being able to iterate lets you not only solve the problem, but REFINE the solution to make it as user-friendly as possible. User-friendliness is extremely important, because if a feature is not user friendly, the likelihood it will be used goes down significantly. In other words…if the software “solves the problem” but is so confusing/inefficient/difficult to use that no one uses it, it hasn’t actually solved anything!

• ubiquitous language
• people can think they know what they need, and actually not
• you make assumptions far too early