LESS Engineering Principles

Most problems in technology delivery are fuzzy; requirements are incomplete, the definition of done is negotiable, so many options for what to do next. There are plenty of standards, frameworks and patterns that could be applied; some have disadvantages that are obvious, others have advantages that will diminish over time. Technology moves too quickly for today’s best choice to still be a good idea tomorrow; there’s always one more refactor.

There are a lot of routes you can choose if you don’t know where you’re going. You need principles to guide you to make the right choice. In this post I’m going to share a set of engineering principles that have guided me through my career delivering complex technology projects: LESS:

• Lean: Maximise value with minimum effort

• Ethical: Be of real benefit to the people we wish to serve

• Scalable: Grow incrementally, never rebuild

• Sustainable: Use diminishing resources responsibly

Lean by design

Maximise value with minimum effort.

• Eliminate Waste: wasted work does not serve our constituents. Be vigilant for: partial done work, extra features, repeated learning, task switching, waiting, handoffs, defects, opportunity cost.

• Build Quality: spending time on quality eliminates later waste. XP techniques still work: pair programming, TDD, code reviews, CI trunks. DevOps should build tools to make it easier to code with quality than not.

• Build Knowledge: knowledge is not just documentation, but well-crafted code, shared understanding, efficient agentic context, meaningful analytics.

• Defer Commitment: ruthlessly prioritise; defer building out features until (just before) the market demands it, just in case they don’t. Leverage tech debt mindfully, pay it back diligently.

• Ship-Learn-Repeat: shorten feedback loops, MVP to prove one hypothesis at a time. Software value is measured in fitness for use and not in conformance to requirements. Experimentation is not wasteful when it increases learning.

• Empower the Team: each team should possess all the tools, skills and autonomy to deliver value to market.

• Systems Thinking: the technology solution is not the whole solution; developers should collaborate to understand the people and processes.

Unless we’re building for ourselves, we’re building for other people. Engineers creatively find that sweet spot between company strategy, product-market fit, capability, and value delivery. Not working in that sweet spot is wasteful of the limited resources we have, so is also disrespectful to the people we want to serve.

Ethical by design

Be of real benefit to the people we wish to serve.

• Trustworthy, Responsible and Accountable: our product is private and secure, not because legislation demands, but because it’s the right thing to do.

• Fairness and Justice: even if our product is inclusive and non-discriminatory to cohorts, it may not be so for every individual; we need methods for identification and redress.

• Of Benefit to Users (not just investors): if we build a great product that people can’t live without then the investment and profit will naturally follow.

• Does No Harm to Society: does not perpetuate structural injustice, does not have unfair cost/benefit distribution.

Being ethical isn’t a choice, it’s non-negotiable. Happily, being ethical is also a product advantage. The same behaviours that yield ethical decisions also yield great product design. Not being ethical cedes a market opportunity to a competitor.

Scalable by design

Growing incrementally is better than rebuilding.

• Scale Learning: capacity to learn should scale faster than the capacity to build.

• Use Scalable Architecture Patterns: not anticipating scale is to build in fragility.

• Scale Just-In-Time: over-provisioned resources are wasted investment.

• Refactor First, Rebuild Last: relentlessly refactor. Keep "ripping out and restarting" as an option, but limited in scope.

The cost of fixing the platform to scale compounds; both the market and technology move forward whilst you raze to the ground then rebuild, making catching up even more costly. Refactoring is a muscle that should be exercised regularly. Deciding how and when to refactor means being confident in understanding where the next binding constraint will be, and learning the capability to fix it before the constraint becomes critical. If rebuilding everything from scratch is the best option, that usually means not enough scalability was designed in.

Sustainable by design

Use diminishing resources responsibly.

• Carbon: Build applications that are carbon (fuel) efficient.

• Electricity: Build applications that are energy efficient.

• Carbon Intensity: Consume electricity with the lowest carbon intensity.

• Embodied Carbon: Build applications that are hardware efficient.

• Energy Proportionality: Maximise the energy efficiency of hardware.

• Networking: Reduce the amount of data, and distance it must travel across the network.

• Demand Shaping: Build carbon-aware applications.

• Optimisation: Focus on step-by-step optimisations that increase the overall carbon efficiency.

Engineers still find ways to hold Moore’s Law to be true. And as compute increases unabated, resources are consumed voraciously. Today’s agentic workflows are already optimising tokens per watt as a key metric. As with Ethics, Sustainability is not optional, but good economics.

Thinking about sustainability will safeguard Intergenerational Justice; we won’t limit the resources that future generations will have at their disposal by overusing the same resources today.

LESS Decisions

There’s always more work that we could do than we have capacity to do. The question is always: what should we do next? Viewing the work through the lens of LESS can help you make the right decision.