3 Tips for Applying “Measure Twice, Cut Once” to Software Engineering

There is a saying that I learned when I was growing up, “Measure twice, cut once.” It was sage advice that I often heard when building something with my dad or when I was under the tutorage of a senior engineer at robotics club. The idea is that we should always be double-checking our plans for accuracy before we proceed in implementation; otherwise, a mistake might be made that will not only waste materials but also time. Unfortunately, following this old proverb advice is hit and miss within the software community, resulting not in wasted materials but a lot of wasted time. In today’s post, let’s examine three tips for how we can plan better in software engineering to avoid wasting time.

Tip #1 – Develop a Software Architecture

I know that I talk about software architectures a fair amount, but it’s because I’ve found that it dramatically helps me plan out my designs and minimize my software development cycle time and cost. It’s not just me. I’ve also seen the same improvement in my client’s efforts as well. Software architecture is the blueprint for the software that will be built and contains all the major components, their inputs, outputs, and interactions.

I often will work with two different software architectures, one that is high-level and abstract from any hardware and a second that is low-level and takes into account the hardware details. The high-level architecture helps a developer design the scalable, flexible business logic for the application. It is completely independent of any low-level hardware, accelerators, and language details. The high-level architecture is often at a level of detail that allows non-software engineers to understand and approve what is happening in the system. The low-level architecture on the other hand becomes a document that the developer can use to implement the software. It provides design patterns, recommendations for leveraging hardware components to improve performance, and so on.

Related:Embedded Software Trends Expand in 2020

Tip #2 – Experiment with Design Elements

When I was a junior engineer, I often found that I just wanted to jump in and start writing the code. It wasn’t because I wanted to skip an important element of the design cycle, it was just that I didn’t know what I didn’t know and needed to dig into the details to formulate an appropriate solution. I suspect many developers feel like they can’t fully understand the problem until they start writing code and this is a feeling that even senior and well-experienced developers have.  

Any solution requires multiple libraries, middleware components, drivers, and so forth that can be hard to pull together an effective design for without getting our hands dirty first. Developers don’t have to jump straight to writing production code though that they will have to continually rewrite. The alternative is to spend some time digging into the details while the software architecture is being developed. Developers can easily design some simple experiments to understand the overhead of an RTOS, how quickly a driver will likely respond and so on which will help them to bound their design and in turn lead to a faster software implementation.

Related:Developing an embedded software build pipeline

These side experiments shouldn’t be looked at as production code, but instead quick and dirty investigations designed to gain the understanding necessary to properly write the production software.  

Tip #3 – Leverage Agile Design Methodologies

Agile design methodologies have become engrained in many software developers and thankfully for good reasons. I’ve found that leveraging Agile methods such as storyboarding and sprint planning to be extremely useful for planning. Software nearly always takes longer than planned but leveraging a good Agile tool can help developers understand the workload, record their time implementing specific features and keep their team updated electronically (which can help decrease time wasted in meetings).

Speaking of meetings, my favorite meeting to have for software developers is just a simple 15-minute stand-up. I’ve found that a lot of teams get bogged down in having meeting after meeting which can kill productivity. Minimizing meetings and keeping meetings to no more than 30 minutes can help a team focus on getting to the point and back to their keyboards.

Conclusions

In my experience, I’ve found that software implementation and feature development go much faster and smoother if development teams (and myself) take the time to design first and implement second. In other words, if I carefully plan what it is that I’m writing, I find that I have a lot less rework to do and save myself time. It also saves me a lot of debugging time as well! The tips we looked at in this post should help the reader start measuring twice and cutting once. While they are high-level themselves, they should spur some ideas on where the reader can look at digging deeper.

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost, and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees which include a Master of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter.