How to determine if your software development business is not healthy? And what can you do about it?

What do we mean by an unhealthy software business?

This means the business is getting dangerously close to a point where the entire business is going to come to a halt. Ways that this can happen include going bankrupt, having software that is too complex so that no one wants to learn it and improve it, or the business is unwilling to allow its engineers to improve it, or the engineers are quitting because they are not growing (and I don’t mean from the perks!).

The Business

An unhealthy business could be caused by multiple things.

For this article, I’m going to focus on the profitability of the business and how that relates directly (in most cases) to the successfulness of its software as the most prominent sign of whether a given software could prosper in the market or not.

Sometimes, a business might get too focused on the software development process and forget about the profitability of the business itself.

For instance, Twitter is considered the de-facto of software when it comes to the standards of Scala, but it’s profitability isn’t as large as it’s effectiveness in the technology itself.

This is a big indication that the business, its software, and its engineers haven’t reached quite the right balance, which results in an unhealthy business overall.

A good marketing strategy and business study and financial management should take care of the business profitability part without going into too much detail about how to handle these issues as they differ from business to business.

The Engineering Process

The other symptom is the software process itself.

The diagnosis of an unhealthy software development process, is simply a process that requires too much manual work of what could be automated, or it requires a lot of time (think unnecessary meetings and too many levels of decision making) before reaching a decision to explore a certain feature.

This results in the developers losing interest in participating in the process as it becomes a mind-numbing process which defies the entire purpose of writing software (automating something that used to be done manually in any given period).

Another symptom is the complexity of the process itself even if it was automated, a bad architecture or the process of pushing new features or fixing defects is time-consuming activity, or the code itself is complex (as in hard to understand and maintain).  In such a case, revisiting coding standards, introducing better architecture and changing the process of pushing features and code reviews is a must.

The Engineers

The third most important aspect to consider when determining the health of any given software business are the engineers involved in writing the software.

A lot of businesses, consider taking care of engineers is only the base salary and the perks.

But, engineers become more fulfilled when the business invests in their growth, from an educational perspective.

In software, the best way to invest in an engineer’s growth is to have him get involved in practical experiments where he gets to try to learn about new technologies and become a storyteller (as I call them) about how to use a certain technology works for a certain business purpose.

Judging from my personal experiences in the last decade or so, I have seen a lot of businesses that invest so much in the perks and salaries and benefits for their employees, but they don’t understand that software engineers have a whole different set of growth mindsets, which go beyond their basic needs.

Think of it this way, anyone can provide a salary, there will always be this other “shiny” company that provides better perks and better benefits, but only few will invest and encourage the experimentation and growth as a fundamental part of the business itself.

When the business invests in its engineers it will automatically leverage the software process. As the more educated and experienced engineers become, they will become more intelligent in building a more efficient software development processes.

More so, engineers will eventually start contributing to the business by giving a different perspective on how to tackle a certain business need such as attracting more customers to the business through software.

When the engineers are happy, that’ll form an ownership mentality that will have them do their best to make sure their software (their baby) continues to grow and flourish which will eventually encourage them to provide some input to the business which will hopefully result in a more profitable business.

At the end of the day, any software development activity, let it be business, process or engineers-related that doesn’t directly benefit the business, the process and the engineers involved would be considered a waste of time for everyone.