We are Purple Crane, software developers who create bespoke software products for SMEs. These products and applications improve what our customers do and how they do it. With decades of experience – and happy customers – behind, and a future of constant innovation ahead, there’s just one problem. How to describe what we do…
No business customer commits money to a technology purchase without knowing what it is or does. So, for manufacturers and vendors, explaining why their product or service solves more problems/makes life easier than a rival is – literally – the million-dollar question. And sometimes rather more than that.
Getting the message right is a make-or-break issue. Technical enough to be credible, but not baffling. And the tone is paramount. Consumers don’t like being patronised (we’re not idiots) or intimidated (we’re not scientists or technicians).
For the SME, particularly a start-up, the right bespoke software can be a genuine gamechanger. But explaining software’s abstract benefits can be tricky. After all, often there’s nothing tangible or physical to show. So, how do we explain what we do – how the software and services we design, create, and deploy could benefit them?
Figure of speech alert!
The best way to describe a thing – a product, process, or service – to those unfamiliar with it is to compare it to something we all find relatable, at least in principle. The go-to simile for software development is building or construction.
The software lingua franca borrows plenty of these similes; software ‘architects’ and ‘engineers’ work with ‘project managers’ to engage in ‘construction’, that ‘builds’ software, which has ‘architecture’. All words that conjure up images of people in hard hats, Hi-Viz, carrying rolled plans and blueprints.
Site test
Construction and software development projects demand specific skills most people don’t have. Both require an architectural and structural design phase, but after this the comparison loses relevance. Bricklaying and coding aren’t really the same, as much as we’d like the analogy to work.
Because once client and contractor have reached agreement on scope, timescale and what the result will be, the build begins. In physical construction the contractor wraps up each phase before commencing the next until there’s a finished piece and, snagging aside, that’s it. But that’s not how software development works.
Can I just change this?
While creating a physical structure is certainly iterative, and produces a tangible result, ‘building’ doesn’t reflect the more flexible, input-led process of software development, which blurs the edge between design and delivery.
The building-themed etymology probably references the waterfall method of writing software which flows like a waterfall through the analysis, design, development, and testing phases of each project.
With agile software development, developers and customers are more in sync, working together in a shared process that may change and the work isn’t done until the product or service goes live. And that’s often just the beginning.
The ability to constantly adapt and change – to evolve – throughout the process with a result that is never complete sets it apart from building and construction. Every phase is agreed, and on we go, until the potential for innovation ends. Which, hopefully, is never.
Is there a better analogy?
Probably not. That’s because software development is a process that builds and strengthens businesses, careers, and futures, not physical structures. Aside from finance, nothing else can make the claim. So, if you want to deconstruct software development, or build something amazing, speak to us. No hard hat required.
