Software development is often misunderstood. From the outside, it can look like a purely technical craft, focused on code, tools and speed. But in reality, it is far more about judgement, trade-offs and understanding the problem you are trying to solve. Developers need to understand why a piece of work matters, not just what they're being asked to build.
The syntax myth
If you were to ask the average person what a software developer does, the common assumption would be that they sit down and write code all day. Much like how mastering a foreign language seems insurmountable to a novice, coding is often perceived as magic. Therefore, it is reasonable to assume that writing syntax is the hardest part of the job.
This is also why we keep hearing that, in the age of AI, developers will soon be made obsolete. If you believe that writing code is the hard part, then that conclusion feels logical.
In reality, implementation is rarely ever the bottleneck. For an experienced developer, writing or reading a block of code is not inherently difficult. Where the real challenge lies, and where the true value sits, is in system design, domain modelling, and managing the trade-offs involved in moving data through a complex, evolving system - one layered with assumptions you may not even know you're making.
Delivering value, not just code
So what really is the job of a developer? It is to deliver value to the business. To quote Chris Read: "Until your pretty code is in production, making money, you've just wasted your time."
Despite the theatrics of exotic-sounding technologies and the jargon that surrounds deploying production systems, delivering value is the crux of what we do and why we are employed.
To do this well, we need to model the reality of the business: the rules, constraints and processes that govern how it operates. In software engineering, this approach is known as Domain Driven Design (DDD). At Zeti, that domain is complex, spanning decarbonising asset finance, telematics and the EV ecosystem. Getting the interactions between these entities right is one of the hardest parts of the job.
At its core, software engineering is about moving data securely and efficiently, and then presenting it in ways that unlock untapped insight. If the underlying assumptions or domain models are wrong, the resulting code becomes brittle and difficult to extend.
Thus, to deliver real value, developers need to be seen as strategists rather than simply as executors.
The "Jurassic Park" trap
As software engineers, we are empowered by the knowledge that if you can dream it then you can (probably) build it. This is true more than ever in the era of AI. The question then becomes not whether we can build something, but whether we should. It was Dr Ian Malcolm in Jurassic Park who observed that scientists were "so preoccupied with whether or not they could, they didn't stop to think if they should." Although a line from a film about resurrecting dinosaurs, the sentiment translates remarkably well to software development.
Just because we can build something (and faster than ever with AI), doesn't mean we should. Developers often act as the filter between technical possibility and strategic viability. At Zeti, being a small but highly capable team means we see the impact of these decisions almost immediately, for better or worse.
Context is king
So, how do we navigate these decisions? The answer is context.
If the job is system design and managing complex architectures, it cannot be done in isolation from the wider business. While developers can decide how to build something, if they don't understand why they're doing that piece of work then they lose sight of the business goal.
This is vital because one of the core principles in software engineering is that everything involves trade-off: speed versus quality, simplicity versus stability, scalability versus performance. As Marvel's Thanos once said, "Perfectly balanced, as all things should be," but a developer cannot choose the right balance without understanding the commercial context.
Is this a prototype designed to help close a deal where speed matters most? Or is it foundational infrastructure that will underpin the platform for years where stability should take precedence? At Zeti, we prioritise sharing customer conversations and the reasoning behind decisions. That context allows developers to make informed micro-decisions autonomously, without constant escalation, and is a key reason we are able to move quickly without losing alignment.
Problem solvers, not solutionisers
This leads to a simple but important request: give developers a problem, not a solution.
It is natural for users of software to jump straight to solutions - "If only there were a button here" is a familiar thought. However, a developer who understands the internal data flows and constraints of a system may see a different path to solving the same underlying issue.
Our first question is usually: what problem are you actually facing?
It then becomes our responsibility to determine the appropriate technical approach. But ultimately, the technologies used, infrastructure we deploy, and code we write are all just mechanisms for solving real problems and reducing friction for users.
Ultimately, the bottleneck in software development has never been technical feasibility, it is strategic clarity. When developers are given context, treated as strategic partners, and trusted with the "why" rather than just the "how," teams can avoid the Jurassic Park trap of building things simply because they can. Instead, they can focus on building solutions that genuinely improve how people work and the outcomes businesses achieve.
FAQs
Why should developers understand the business problem?
Writing code is only one part of software development. The real challenge is understanding the business problem and designing a solution that delivers lasting value. When developers understand the "why" behind a project, they can make better technical decisions, challenge assumptions, and often identify simpler or more effective solutions.
Why should businesses involve developers in strategic decisions?
Developers bring a unique perspective on technical feasibility, scalability and long-term maintainability. Involving engineering teams early helps organisations explore a wider range of solutions, reduce costly rework and build products that better meet customer needs.
How does customer context improve software development?
Developers build better software when they understand how customers actually use a product. Sharing customer feedback, operational challenges and commercial objectives enables engineering teams to make informed decisions without constant direction. The result is faster delivery, better prioritisation and solutions that solve real business problems.
Will AI replace software developers?
AI is transforming software development by helping engineers write code more efficiently and automate repetitive tasks. However, it cannot replace strategic thinking, system design, domain expertise or an understanding of business trade-offs. The greatest value developers provide is deciding what should be built and why.
Why are trade-offs important in software development?
Every software project involves balancing competing priorities such as speed, scalability, flexibility and long-term maintainability. The right decision depends on the business context. A prototype designed to test an idea may prioritise speed, while a production platform needs to support growth, reliability and security over many years.
How does Zeti approach software development?
At Zeti, software development begins with understanding the customer and the business problem. By combining expertise in asset finance, clean transportation and connected vehicle data with modern cloud architecture and AI-assisted development, our engineering team focuses on delivering practical solutions that improve customer outcomes rather than simply implementing requested features.