Skip to content

Maximizing Software ROI: Lessons from Return on Software

In software development, it’s easy to get lost in the weeds—endless debates over tooling, methodologies, and frameworks. But at its core, software development is an investment, and like any investment, it should be judged by its return.

Steve Tockey’s Return on Software tackles this head-on, arguing that software engineering must be treated as an economic discipline rather than an art form. This book strips away the fluff and asks a crucial question: Are we getting real value from our software efforts?

Let’s dive into some of Tockey’s key insights and how they apply in real-world scenarios.

1. Software is an Economic Activity

At its core, software development is about delivering value, not just writing code. Tockey emphasizes that organizations should focus on maximizing return on investment (ROI) rather than getting caught up in technical perfection or developer preferences.

Key Takeaways

  • ✅ Cost is not the only metric—time to market, maintainability, and adaptability matter just as much.
  • ✅ Productivity ≠ Value—churning out code quickly doesn’t mean you’re building the right thing.
  • ✅ Decisions should be economic, not emotional—picking the latest trendy framework isn’t justified if it doesn’t improve ROI.

2. The Cost of Poor Software Engineering

Many software teams underestimate the hidden costs of bad practices. Tockey highlights how technical debt, unclear requirements, and rushed development create financial black holes that swallow future budgets.

Practical Considerations

  • 🚨 Requirements matter more than you think. Fixing a defect after release can be 100x more expensive than catching it early.
  • 🛠 Maintenance dominates costs. The bulk of a software system’s lifetime cost isn’t development—it’s keeping it running.
  • 🎯 Quality isn’t a luxury. Delivering buggy software fast doesn’t save money; it creates expensive rework later.

3. The Myth of Efficiency vs. Effectiveness

A common mistake in software development is optimizing the wrong things. Many teams focus on developer efficiency (velocity, lines of code written) rather than effectiveness (delivering real business value).

Shifting the Mindset

  • 🔄 Instead of measuring success by how much code is written, measure it by how much value is delivered.
  • 👥 Favour small, high-impact teams over large, slow-moving development groups.
  • 🏗 Architectural decisions should be ROI-driven, not tech-driven. Pick the stack that maximizes long-term returns, not the one that’s popular today.

4. Investments in Software Engineering Pay Off

Tockey argues that proper engineering practices—like thorough requirements analysis, design reviews, and testing—are investments, not costs.

Why This Matters

  • 💡 Cutting corners early leads to exponential costs later.
  • 🔍 Code reviews, automated testing, and solid architectures improve long-term ROI.
  • 🛡 Good engineering doesn’t slow you down—it prevents you from sinking later.

5. The Fallacy of the "Silver Bullet"

Tockey dismantles the belief that a single methodology, technology, or framework can drastically improve software productivity overnight.

Key Lessons

  • ❌ There’s no magic tool that will instantly fix software development problems.
  • 🔄 Process improvements are incremental and require discipline.
  • 📊 The biggest gains often come from consistent application of best practices, not flashy new tools.

6. Understanding the True Cost of Change

Software is never done—it evolves. Tockey emphasizes that understanding the cost of change is crucial for long-term ROI.

What This Means in Practice

  • 🔄 Change is inevitable—architect for flexibility, but don’t over-engineer.
  • 🕵️‍♂️ Not all change is equal—some features justify high flexibility, others don’t.
  • 💰 The later a change happens, the more expensive it gets—invest in good up-front design.

7. The Importance of Measurement

Tockey argues that if you can’t measure it, you can’t manage it. Too many organizations make gut-feel decisions without solid data.

Actionable Insights

  • 📊 Measure productivity by value delivered, not raw output.
  • 🕰 Track time spent on rework and maintenance—it’s often higher than expected.
  • 📉 Use data-driven decision-making, not assumptions.

8. The Hidden Costs of Poor Requirements Gathering

One of Tockey’s biggest points is that bad requirements lead to expensive fixes later.

Why This Matters

  • 🧩 A missed requirement early on can cause months of rework later.
  • ⚡ Rushing into development without clear goals leads to wasted effort.
  • 🔄 Investing in upfront requirements saves money over the long run.

Final Thoughts: A Pragmatic Approach to Software ROI

My Personal Takeaway

I’ve worked in software engineering and architecture for years. I’ve seen firsthand how decisions based on short-term speed over long-term value can come back to bite teams. Return on Software reinforces what I’ve always believed:

  • The best software development isn’t the fastest—it’s the most sustainable.
  • Architectural choices should be business-first, not tech-first.
  • Cutting corners to ship quickly almost always leads to pain later.

If you’re making software decisions—whether at the architecture, process, or team level—ask yourself:

💡 Will this maximise ROI in the long run?

If the answer isn’t a clear yes, it might be time to rethink your approach.