We’ve all had the experience of ordering something, waiting patiently for it to be designed, built or shipped, and the fun of getting stuck in when it arrives. But sometimes, the excitement is brought to a swift, depressing end by the realisation that what you got wasn’t really what you needed after all. Maybe you’ve been sent the wrong thing, or worse – it dawns on you that what you asked for was, well, shit.
Delivering shit software, because that’s what you asked for
I’ve been thinking about this since I heard this choice phrase float across the office the other day. It was a flippant remark intended to lighten the mood and it got a laugh, but it also got me thinking about the number of times we meet companies who’ve had their fingers burned by outsourced software projects that haven’t delivered to their expectations.
To be fair, even when outsourcing goes awry the end result can still be a product that ticks the boxes, but just isn’t very good: maybe it’s clunky, hard to use or not scalable. Often, though, the issue is more that the project solves the wrong problem, or that new systems don’t work effectively with existing infrastructure. Sometimes nobody remembered to ask the users how they actually work and what they need.
Delivering shit software is highly damaging to the reputation of the industry as a whole, so why is it that so many development companies still serve it up? I think there are a number of core issues.
Challenge the brief!
A bad result is rarely the fault of the client. An experienced software company knows the importance of understanding both the project, and its wider context and purpose. It’s a developer’s job to push back, pick holes, throw stones and generally pull your initial brief to pieces.
If your chosen team just sits there nodding before accepting a project completely at face value, unchoose them. If you don’t, there’s a chance they’ll deliver shit software – because that might be what you’ve asked for.
Communication
Software development, eh? Even small projects can be highly complex, and a typical one might last many months, involve a number of different teams, and have to satisfy requirements from stakeholders across the business. That’s challenging enough for an in-house team, but throw in an offshore (or nearshore) developer and things can get properly hard.
There’s no substitute for a software team that invests time in meeting stakeholders and users within your business, and keeps in regular communication with them during the project. A trusted relationship is essential to smooth progress, but it’s also a basis for honest discussion if an expectation or quality-gap develops. Don’t assume that silence is a sign of quiet competence – it’s usually the opposite.
It’s about the business!
Any software house worth its salt has teams of great coders, but that’s no help if they’re cave dwellers, more interested in code than the people using it or the business outcomes it’s there to deliver. You’re not buying software because we like to code, you’re buying it because you’ve got a problem you need to solve, or a business opportunity you need to exploit.
Really being good at software development means understanding, above all else, what you’re creating, why, and who’s going to use it. If your software team doesn’t start with the focus of the project, design from the user story, and test against the desired business outcomes, they might as well be doing it for themselves.
It’s about you
So that’s them. What about us? We build custom software, so we ask custom questions. You pay us to solve problems in your organisation, so we get to know your organisation and the context in which it operates. And we talk to the people who’ll use what we create.
The results, we hope, will be what everybody asked for, and exactly what you were expecting.
