Managing software development effort

How to measure productivity and make optimal tech choices.

Code is sin. Use in moderation.

Software development and manufacturing are different beasts. Metrics to measure productivity and effectiveness in these two streams of engineering are inherently incompatible and yet, software developers continue to borrow ideas, processes and metrics from the latter. Especially, the idea of measuring progress/productivity through measuring lines of code (loc).

Tech decisions matter — choices, based on ridiculous metrics, lead to tech debt and impact business significantly.

The velociraptor is a not so subtle hint at outcomes of bad tech choices

Ironically, most businesses have failed to borrow the one concept they should have — measuring ROI of software development effort. More on that later.

So, how do you manage software development?

Jeff Atwood, co-founder of Stack Overflow, referencing Will Shipley, postulates a set of opposing dimensions on which software development decision trade-offs are to be considered. Let’s take a look at these:

  • Brevity: Write less code. Or none at all.
  • Featurefulness: Meeting all specifications. Both real and imagined.
N.F.R — Not a frigging requirement
  • Speed of execution: Performance of code.
  • Time spent coding: More obviously at odds with the other factors. Want beautiful and performant code — it will cost you time (and $$!).
  • Robustness: Well, your code does need to perform in all real life scenarios. This Q.A business is not such a bad idea after all.
  • Flexibility: Code adaptability.

Much heuristics, such confusion. Help me, Senpai!

My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. — Dijkstra(1988)

Atwood, Wil Shipley and Rich Skrenta do a good job of backing old man Dijkstra with some contemporary wisdom and data. They make solid arguments for picking brevity as the primary heuristic and optimising for the rest when needed.

tl;dr for these arguments (in keeping with the now apparent theme of this post) :

  • More code = more bugs: Code will rot. The relationship between lines of code and bugs is completely linear.
What happens when you have a large codebase
  • More code = less flexibility and functionality (sounds strange, right?).
  • More code = more developers = more cost: Unicorns won’t manage code. Developers have to.

So, the rule of thumb is — optimise heavily for reducing lines of code first, and then play around with the other factors on a case by case basis.

Every ShowHN thread ever!

Sounds good. So, how do I reduce LOC?

  1. Use OSS — Communities matter. They take care of heavy lifting , so you don’t need to write code for solved problems or available abstractions.
  2. Don’t DIY. In fact, don’t do it unless absolutely necessary. Buy off-the-shelf tools. They solve a specific problems and have businesses built around solving said problems. Choose wisely but do NOT write code your company is not in business for.

3. Microservices: Or rather, multi-services. Microservices is challenging for DevOps. But, with contemporary automation and tooling, it’s becoming feasible to think of services as components that can be dropped in to extend functionality or re-usable code that prevents writing of repetitive code.


Code is the enemy. Resist the urge to write code. Rebel against features. Whatever you do, aim for brevity.

Hasura is an open-source engine that gives you realtime GraphQL APIs on new or existing Postgres databases, with built-in support for stitching custom GraphQL APIs and triggering webhooks on database changes.