The Quest for Engineering Efficiency

There is a lot of focus right now on doing more with fewer engineers. New tools promise revolutionary productivity gains, new platforms democratize development, and every conversation online buzzes with efficiency breakthroughs.

Sound familiar? It should. We've been here before—multiple times.

Let's dive into the history of efficiency-seeking in software engineering. Understanding these patterns can help us navigate today's promises and pitfalls more effectively.

A Foundation: Brooks' "No Silver Bullet" (1985)

Fred Brooks distinguished between two types of efficiency challenges:

"Accidents" - Easy optimizations you can make with better tools or processes 

"Essence" - Hard optimizations requiring lots of experimenting and complex engineering

This dichotomy remains remarkably relevant today. It’s more feasible to target accidents. The hardest gains require tackling essence.

The 2000s: Two Familiar Questions Emerge

Question 1: Engineering Tools 

The argument: IDE efficiency (i.e. emacs pedals vs. custom vim keyboards). I would go to engineering meetups where the entire discussion centered on which tools make you the "best engineer."

The reality: Different engineers succeed differently, and tool preferences are highly personal and context-dependent.

Question 2: Low-Code/No-Code Engineering

The promise: Open up custom development to non-technical users, eliminating the need for trained engineers.

A cautionary tale from lab automation: Many lab automation systems in this era had low-code interfaces that couldn't be circumvented. I remember working on a system where it took 30 minutes to program a routine that would have taken 5 minutes in code. Those systems opened up the user base but made programming far less efficient. Additionally, there were things you just couldn't do if you could just "speak code" to the system.

Today: History Rhyming with Shinier Tools

Question 1 (2.0): Engineering Tools Battles

Same argument, different weapons: Every time you turn around online, there are engineers arguing over what makes you the "best engineer"—only now it's Cursor vs. Claude Code vs. traditional IDEs.

The reality: The engineer who can quickly build anything with their perfectly configured Emacs setup won't suddenly become dramatically better with Cursor. Different engineers are different. Different tools work better in different circumstances and for different people.

Question 2 (2.0): Fully Generative Code Systems

The promise: Newer generative systems can do so much more than their predecessors, but many of the same drawbacks persist.

Current limitations:

• Code quality gaps - Generated code often isn't on par with what skilled engineers produce
• Engineer slowdown - Good engineers can get bogged down trying to build on fully generative foundations
• Hidden issues - Security vulnerabilities and architectural problems can lurk beneath seemingly functional code

The Bottom Line: Takeaways for Scientific Organizations

If you're not an engineer:

Don't get caught up in the tools debate, which can be hard to understand and will continue indefinitely. Focus on your actual problems and outcomes, not the latest efficiency promises.

If you want real efficiency gains:

Ask the fundamental questions:

• What are you trying to accomplish?
• For whom?
• How will you test success?

Technology moves fast, so:

• Solve clear problems with focused solutions you can test
• If your testing reveals issues, question why and decide whether to invest in optimization or wait for better solutions

What efficiency challenges are you solving in your scientific software projects? 

Connect with us on LinkedIn to share your thoughts.

Alan Barber, CEO

Accendero Software

If this perspective was helpful, please share it with other teams navigating today's efficiency promises.