Software Engineering Mindset Model: A Proven Approach to Software Development Success

Discover the best practices for software engineering and learn the mindset model that can help unlock the full potential of your software engineering team.

Shan Huang, Chris Hayner

Software Engineering Best Practices: a Mindset Model

Let’s start with a few simple truths. First: software engineering is hard. Second: software engineering is also an art form that often ends up feeling like a single person mission. And while going it alone often feels like the “easier” way to go about solving a problem in coding, it’s not always the “best” way- especially over time.

Greetings. My name is Shan Huang, and I am the Founder and CEO of Forma Cloud. I have been deeply involved in software engineering throughout my career. From my early days as an individual contributor to my more recent roles as a manager and executive responsible for leading massive teams and initiatives, I have seen the software development process from all angles. I have leveraged that experience to create the Software Engineering Mindset Model (or, “SEMM”). SEMM makes what can be a very messy operation into something organized, streamlined, and efficient. The Mindset Model is composed of software engineering best practices that make sure our code base can be the best it can be- not just now, but over the long run.

Since our inception, Forma Cloud has leveraged SEMM. Our leadership and our software engineers have embraced SEMM, and our results speak for themselves. It might seem like a rigid software engineering model would mean a slower development process, but it’s actually the opposite. Using SEMM at Forma Cloud has resulted in a more understandable code base, and most importantly, far fewer bugs. Taken together, this has added up to a significant time savings across our software engineering projects.

I would like to share my Software Engineering Mindset Model with you in this article. Before I get into the details of SEMM, though, lets discuss some of the problems programming teams can run into when operating under the ‘old’ model of Software Engineering.

Software Engineering is Not Just About Solving Today’s Problems

One thing that dooms a lot of programmers is the pressure to move fast. It’s very easy to fall into a short-term mindset. Left to its own devices, the software development process often ends up being something like:

1. Identify a problem.
2. Solve that problem.
3. Move on to the next problem and repeat.

This is unquestionably a very satisfying way to do it- after all, you’re solving problems and logging lines of code. The trouble is if these issues are solved in isolation, they may only be a partial fix. This is particularly true in large and/or messy code bases- you may think you are solving an issue, but that ‘issue’ might have only existed because logically it needed to be there to solve some other issue.

Here is an example that illustrates this.

A Software Engineering Cautionary Tale: When A Random Sleep Timer Isn’t Really Random

NOTE: The following is a real-life story based on my own prior observations in the industry. Some details have been left out or simplified for the purposes of anonymity.

Some years ago, Company X ran a program that managed customer data based on a numerical user ID and a private PIN. One day, a software engineer was looking through the code base, trying to increase product efficiency, and noticed that there was a line that simply caused the program to sleep for one second. Every time a user ID and PIN was processed, the entire back end would sleep. There were no comments explaining this, and it didn’t make any rational sense to the engineer. The engineer assumed that this was left over from some development troubleshooting and wasn’t necessary anymore. So, following the three-step model from above (Find problem, fix problem, repeat), the engineer deleted the line that caused the program to sleep. No other issues seemed to present themselves, so the engineer moved on.

Here’s the problem: that one second sleep actually did have a purpose. When an ID and PIN combination was created it used epoch time as a variable to help with randomization. The sleep was put in place to ensure that no user ID/PIN combination was created at the same epoch time as any other. By deleting the line that made the back-end sleep, the engineer inadvertently created a situation where PINs could be guessed for consecutive user IDs. And, unfortunately for Company X, this issue was so subtle that it took a long time for them to notice it was happening. Unfortunately, hackers figured it out much more quickly. This ended up costing Company X a lot in the long run- financially, as well as reputationally.

This problem happened because Company X did not have a software engineering program in place that ensured everyone was working together. And while this situation might be unique to Company X, the lack of rigor around software development is far too common. This is exactly why I developed the rigorous Mindset Model that all our engineers follow- no one here wants Forma Cloud to be like Company X.

Unlocking Potential and Accelerating Team Growth with the Software Engineer Mindset Model

What is Software Engineering Mindset Model and Why it Matters

Instead of the informal 3 step model we talked about above, Forma Cloud uses my formalized 10-step Software Engineering Mindset Model. Here are the steps:

1. Understand and confirm both the problem and the solution
2. Create design doc with requirements and a back-out plan
3. Discussion and approval with the team
4. Actually do the coding (in a development environment)
5. Internal demo and approvals
6. Develop maintenance features (configs / alerts / metrics)
7. Create or modify documentation
8. Sign off meeting and promote code to production
9. Announce and claim credit
10. Define any long-tail or next step tasks

While there is an order to SEMM, it doesn’t have to exclusively be a top-down approach where every step must be executed on every programming task. Forma Cloud employees understand that these are all important aspects to consider, but depending on the problem at hand, they can skip steps (or go back to previous steps) as needed. While these steps are all important, they are not as time consuming as they sound.

What SEMM does is set software engineers up to move deliberately through projects as a team, rather than as individuals who do not know what other contributors are doing. Engineers and managers are both fluent in SEMM, so they can speak the same language regarding the work the engineers are doing. This empowers engineers to have flexibility on what they are working on, and gives managers trust that those same engineers understand what is, from Forma Cloud’s perspective, good quality code. This allows the team the flexibility to understand what is ideal, and the flexibility to adjust according to reality.

Implementing the Software Engineering Mindset Model

Let’s look at the various sections of SEMM in more detail.

Many programmers look at coding as exclusively a step four job- after all, sitting down and writing the code is the fun part. But think about the issue at Company X as we walk through these steps. If Company X had been as careful as Forma Cloud, they would never have had that issue in production.

The first 3 steps (understand, design, and discuss the solution) are all about communication. If a programmer identifies an issue (or is assigned to solve one), their first step is to confirm exactly what that issue is, and describe how they are going to solve it. This is very much in line with the old “measure twice, cut once” mentality from woodworking- we talk about the issue and scope how we are going to fix it before any hands go on keyboards. This has two advantages. First, it makes sure we aren’t inadvertently fixing something in a way that breaks something else. Second, other team members might have solved similar issues before and have a novel approach that might fix the problem faster. If Company X had done just these three steps, they never would have had the issue they had.

Steps 4–8 (write the code, test/monitor, document, and promote) are the longer way to do our previous 3 step process. We build code in a sandboxed environment and observe what changes. We share our work and let others try to find problems. Only after a full round of approvals does anything get promoted into production.

Step 9 (claim credit) is important, and often overlooked. A lot of this software development process is about communication, so this step helps socialize changes to everyone in the company- not just the software engineers. But this step is also about acknowledging hard work. When code is promoted to production, we share that information with the entire company and give credit where credit is due.

In the final step (define long tail/next steps) we look to the future. When a problem is solved, we still have work to do. In large and complex programs and codebases, changes are necessarily incremental in nature. So, step ten allows us to look at what needs to happen next. This might be cleanup steps, or it could be the point in the process where we start again on the next feature.

Conclusion

At Forma Cloud we take great pride in our software engineering. I developed SEMM to help maximize our team’s ability to create great products and have been gratified to see it be so successful. Effective teamwork and communication are essential to this effort. SEMM ensures everyone has a clear understanding of their individual roles and responsibilities as well as everyone else’s. The teamwork, documentation, and rigid adherence to commenting helps to make sense of the code we write, both now and well into the future. The reliance on collaboration also helps us eliminate delays, rework, and most importantly, bugs. Team members support each other and provide valuable insight and direction in all aspects of our products.

Forma Cloud can help you save on cloud costs. Our expert team of AWS engineers and cost management specialists monitor your spending so you can understand and reduce it. We operate via a fast and efficient SlackOps model so we can provide fast and reliable answers to questions about the cost of your AWS environment. Visit us online to learn more or schedule a demo to see our cost management tools in action.