• Are you developing in-house software?
  • Are you satisfied with how focused your in-house team is?
  • Well, think twice because your software might be suffering from DDS Syndrome.

DDSS thumbnail

You can find us on:

YouTube | LinkedIn | Facebook | Twitter | Pinterest


In-house software development provides numerous advantages:

  1. Internal communication means a company can create a software product at high speeds because the expertise is in-house and a focused mindset leads to the development of a team of experts.
  2. The team will be more attached and committed to the success of the software as their involvement with its development is so high.
  3. You get what you want in terms of features, code, etc with everyone focused on the end result.

However, you might still have DDS syndrome – Developer Driven Software Syndrome, where your software is too inner-focused rather than outer-focused. Therefore, we will review the five critical signs that indicate you suffer from DDS syndrome in your in-house software development.

Key issue with in house software development

DDS syndrome is not clinically related to your body but your software. The main symptom is that your software is developed by your developers rather than led by your users. Software should be meeting the expectations of your users. Therefore, if your developers are charging ahead without paying attention to what users want, we end up with developer-driven software.

Symptom 1 – Your in-house software works but not as users expect

A lot of times, this happens when users’ stories or environments are not very clear. So the developers develop the software thinking it should work rather than digging deep and understanding what the end-users want.

Symptom 2 – Software has incomplete or incorrect functionality

We often see requirements that go down a particular path but don’t have all of the offshoots that the consumer really wants. If the software behaves in a way that is confusing or awkward then it has a functionality issue.

☞ You might be interested in: The-best-software-test-strategy-in-10-steps

Symptom 3: Your in-house software does not respond to negative inputs

Your in-house software might be doing what it is supposed to do when the users enter what the developers think they should enter. But what happens if the users enter something the developers don’t expect? In this case, that’s what we call negative input, and the software does not respond appropriately, or maybe not at all.

Symptom 4: Software has incomprehensible error messages

If the software doesn’t respond appropriately, in this case, it could just crash. Or you could get an error message. And suppose the user receives an error message they cannot understand. This is also related to the developer not really empathizing and thinking about users experiencing problems with their software. In this case, developers might wonder, “what do I need to fix the problem” rather than “what do I need to let the user know what the problem was and how they can correct it.”

The end result is not only more defects in the field that need to be fixed but unhappy users who don’t understand how to get past the error.

Symptom 5: More calls to tech support and help desk

One of the key indicators that your software is not answering customers’ needs is the volume of calls you might get from these customers to your tech support. That should be a red flag or at least an indication that things are not going as expected. As we have seen with the 10 success tips for successful software testing, customer support is a fantastic source of data, as you can analyze these support tickets to find out what problems end-users tend to have.


You can find us on:

YouTube | LinkedIn | Facebook | Twitter | Pinterest


You might also like:

Automated testing toolsSoftware testing strtaegy 10 x rulesThumbnail What should you consider waterfall to agile
Test Automation – Key Benefits, Challenges, and Getting StartedThe Best Software Test Strategy In 10 StepsKey difference between agile and waterfall – What if you want to transition from waterfall to agile testing?
By: Philip LewBy: Philip LewBy: Philip Lew