What causes software development to go wrong

Software developers need to know what to do, whether framed as outcomes so they can figure out the details themselves, or prescriptively when inexperienced or not very good. Consequently, someone in ‘the business’ needs to know what they want, first and foremost, so they can communicate it to the developers. Any break or weakness in this chain of information flow results in poorly built software, or worse still, conversations and ideas that never become software.

When software development is more likely to go wrong

New product and proposition development, bespoke and custom software development, integration of backend systems, system rationalisation and retiring end-of-life technology, multiple suppliers, outsourced and offshore development, inexperienced developers, absence of critical roles (eg. requirements analyst, technical lead, quality assurance manager).

I suspect my software development is going wrong

You’ll attend a product demo and be either thoroughly underwhelmed at the progress made or plain angry at the sloppiness that you see, or you’ll lie awake at night worrying that you don’t know what is being delivered, and when (even approximately or on a prioritised basis). These are major indicators that something is wrong with your software development process.

Demos are regularly cancelled or pushed back because of overrunning development items. Infrequent production releases to actual users. Production releases that go wrong. Unexpected outages or data corruption. Spiralling bug counts. Unhappy users when they finally get new software versions. Frustrated developers working in a team with low morale and high staff attrition. These are other indicators to look out for.

How to improve my software development

I’ve never come across an underperforming development team that didn’t also have software requirements problem. Developers don’t know what to do without requirements, and certain chaos ensues. Use cases, agile user stories, FRDs, BRDs, requirements catalogues – the title doesn’t matter, but someone needs to produce it. You don’t have anyone taking care of the software requirements? That’s the first thing to address.

Not knowing what to tell the developers is usually the next issue, particularly if you are building a new product or proposition. That’s because it’s really hard to convert ideas and concepts into well-defined, implementation-ready user stories, thinly sliced and sequenced sprint by sprint. It’s particularly hard if you have a big development team with different skill sets. Each developer needs a prioritised work stack and sufficient work to do, and that’s only possible when you really understand the underlying business need to solve.

Occasionally, the exact thing to build is known but the requirements are falling short in terms of sufficient detail, acceptance criteria, business rules, etc. You’ll see developers becoming blocked in their work, needing conversations to clarify the ask, waiting for system access and environments to be made available etc. Better quality requirements, sufficient time to review them with team members, and consideration for third-party dependencies is usually the solution.

Special consideration for remote development

Remote, outsourced and offshore development brings challenges not present in local development teams. Losing co-location, inability to hustle answers in real-time, inaccessible product owners, different time zones, non-English cultures, the proliferation of boot camp graduates, and overbearing account management all come into play.

However, it is possible to collaborate effectively across multiple time zones, but shifting to asynchronous communication and mostly written forms of communication is required. Remote teams working similar hours to the local business can more readily act as an extension of the local workforce, whereas other offshore teams perform best when responsible for end-to-end work rather than bouncing part-finished WIP between several distributed teams.

How Frank Ray Consulting helps

Our software requirements allow your developers to quickly start building the right thing, and continue to do so as work progresses. Your developers will know exactly what to do and be well supported when doing it. We were once software developers ourselves, so our requirements are implementation-ready and you simply won’t find the same quality anywhere else.

Read more about our services.