We live in interesting times. Software has never been more critical for keeping up with the competition (let alone disrupting industries), and yet, Australian software development companies are dropping like flies. Buzinga collapsed into liquidation in 2017, and Appster followed a year later in 2018. Prior to these collapses, both Appster and Buzinga were heralded as rising stars in the software development industry. In their demise, they left many customers with empty hands and broken dreams.

What happens when a software developer goes broke?

Can another developer pick up where the other left off? Changing developers is rarely and easy undertaking; there's a couple of steps you'll need to take before you can get your software project back on track.

Step 1: Extricate your assets

The first thing you will need to do is retrieve your codebase and other assets, such as prototypes, roadmaps, and deposits from a madhouse of soon-to-be-unemployed developers and hard-eyed liquidators. Your trials and tribulations are only beginning.

Step 2: Look for a new developer

You'll need a new developer, and they'll probably want to scope your project requirements for themselves before picking up the pieces. (Bonus red flag: beware of developers who agree before seeing your project's requirements). Even if they're happy to build to your original developer's requirements backlog, there's going to be a learning curve. In other words, you're going to lose time, and time is money.

Step 3: Go back to Step 1 (optional)

To make matters worse, if you picked the wrong developer the first time around, can you be certain you will pick the right one now? This article will make you a pro at recognising and avoiding developers waving any of these 5 red flags.

A guide for picking the right software developer (or getting out early)

Developing software is complex. This is why most businesses outsource their requirements to service companies such as Appster and Buzinga. Normally, there's no problems. Sometimes, however, software developers can become a nightmare.

Here are 5 red flags you can use when screening potential software development companies.

#1: Your developer fixes the time and the scope

Nothing is certain. Rather than pretending otherwise, software developers should acknowledge this. Failure to do so is a massive red flag!

The two main variables in software projects are the scope of the project (requirements) and the time required to develop these requirements.

Some software development companies fix both these variables. This is called a Waterfall methodology. At first glance, this method can appear to de-risk the development process. This is because your developer commits to both a list of requirements and a deadline. Anyone with any experience with computers will see the risk here.

The principle of the Cone of Uncertainty suggests that estimating the time it will take to complete a project becomes easier over time as you work through the requirements backlog.

Estimations are less accurate the further you are from completion.

This may sound like it's your developer's problem, but if neither time nor scope are flexible, the only remaining variable is quality!

The alternative to the Waterfall methodology is called Agile. Instead of fixing both variables (time and scope), only one is fixed.

If time is fixed, a developer can estimate how long individual requirements will take to complete and work with the customer to ensure the highest possible value is delivered during the agreed time frame.

Alternatively, if scope is fixed, a developer can set about delivering features as they're set forward in the requirements. With less attention paid to time and more paid to functionality.

None of these three methods (Waterfall, fixed time, or fixed scope) is inherently better than the others. However, software developers offering a Waterfall approach should be treated cautiously. As appealing as the certainly of fixed time and scope is, the simple fact of the matter remains: estimations are usually wrong and you run a high risk of impacting the quality of your product.

#2: Your developer only talks to you over the phone/video call

Part of the reason why Appster failed is because they offshored all of the actual development and design of their customer's projects. For some 'onshore' software development companies, little more than a meeting room is actually onshore.

Even if face-to-face meetings with your actual developers and designers are irregular, they're a fantastic boon for communication. Any software development company that hides their greatest assets behind closed doors is doing both themselves and their customers a disservice. Red flag.

#3: Your developer does not release regular, standardised iteration reports

Software development is typically completed in iterations or sprints. At the end of each iteration, your developer should write an iteration report documenting all progress.

WorkingMouse's iteration reports include a reiteration of the initial plan (User Stories), a log of User Stories that were added or removed after the iteration was started, and an outline of the completion status of all active User Stories.

A formalised iteration report helps customers and their developers maintain a clear focus on the state of software. Poor communication after an iteration is a massive red flag.

#4: Your developer has no standardised Definition of Done

Our Definition of Done checklists ensure we're delivering work to a high standard, as well as clearly communicating our progress. These checklists are: Definition of Done Beta and Definition of Done Prod (production or live). These checklists outline specific requirements for marking a User Stories as done.

Our Definition of Done Beta, for example, requires that we've written automated tests for the User Story, our code has been peer-reviewed internally, and we've written documentation.

Armed with these checklists, our customers can be sure User Stories are only progressed when specific requirements are achieved. This maximises both quality and communication.

A developer who decides when requirements are done based on nothing more than personal discretion is waving a red flag big enough to put any matador to shame.

#5: Your developer is wishy washy about their procedures

Always beware a service company that's unwilling to be open about its processes and reasons for these processes.

When we refer to our Way of Working, we are talking about specific processes, collaboration patterns, practices, tools, and principles. Our Way of Working is an overview of the way we work and why we believe it delivers the best results.

If you read our Way of Working, you will find detailed explanations for our definitions of done, our methods for estimating User Stories, and even who attends meetings. Full transparency.

Check out our proprietary process.

Read our Way of Working and decide for yourself if our processes align with your goals and risk acceptance.