We have clients in a variety of industries and one of the most common questions they ask us is “Why does software development take so long?” It is a reasonable question. Unless you have tried developing the tech resources for your company on your own, you might not have been exposed to the process needed to solve a major business problem with technology. We’re going to walk you through the process that goes on and some of the reasons that make technology changes take so long, including:

  1. Finding a solution to address the business need.
  2. Unexpected challenges that come from the solution.
  3. Higher expectations.
  4. Increasing integration points in company software.
  5. The speed at which technology advances.

Lets take a look at each of these.

Finding a solution to address the business need.

Every business is different. Even if they are in the same industry, they function somewhat differently. You have different employees, different cultures, different services, and different business objectives. Obviously some of them overlap, but not all of them. In addition, the software you use is different. This may be because of the software providers you use, the way the admins set it up, or any variety of reasons. This makes it where we have to take into consideration your organisation when creating software to solve a solution.

Before we begin any project, we look at the business need. What problem are we solving? Is it actually going to help your business run more efficiently and drive profit over the long term? Then we’ll need to know information about the software you are currently using, how it needs to work with the new software, and what future software goals you have. Then, we’ll propose a solution and provide an estimate. That’s when the time consuming aspect begins.

Unexpected challenges that come from the solution.

We start by building the solution in a test environment. At this point we are just trying to make sure the functionality works. This can have unexpected challenges, such as bugs in source code, compatibility issues with your current software, and other issues. We know no matter how much planning we do, there will always be some unexpected issue that is easier to problem solve when we arrive upon it so software developers factor the problem solving time into the development time. Fortunately, as time goes on unexpected challenges have become easier to solve because of the vast libraries of code available to software developers today. We can find a solution and fix it with a little research as opposed to trial and error, which was often the case in the past. Despite this efficiency gain, the speed of software development hasn’t improved exponentially. The following points will help explain why.

Higher expectations.

In the past most organisation’s didn’t have high expectations of their software. They would get some software that would solve a specific business need, lets say an inventory management system, but it wouldn’t communicate with their Point-of-Sale (POS) software so periodically someone would have to go through and update it. But over time, companies realised that those two systems should be connected so they integrate them together. That sounds easy just draw a line on a schematic from the POS to the inventory management system. Sounds great right? Well it’s not that easy.

To make that line meaningful, you’ll have to map the items in the POS to the items in inventory. If the items are identical, which might be the case with a online retailer, then matching them together is really easy. If it’s a manufacturer and multiple parts go into a product, then there is much more mapping that has to occur so that when they build a car and ship it off, the inventory management reduces the quantity of wheels, seats, body parts, and more that are in stock.

Then we expect the financial system to update the revenue from the car sold as well as the costs of goods sold, and other appropriate changes. This requires more integrations. The more integrations you need, the more complex the project is and the more time it will take to make sure everything works properly. Higher expectations push the world forward, but they also make the solutions necessary more complex.

More Integrations

I started talking about this while explaining why higher expectations make development take longer, but lets look at it in more detail. Integrations are basically lines of communication. Depending how your data is currently stored, there could be a ton of integrations that need to be achieved or a new database may be necessary to reduce the lines of communication. Lines of Communication are typically calculated as:

Formula for lines of communication
Number of IntegrationsLines of Communication
21
33
510
1045

As you can see, the more software you integrate together the more lines of communication there is, unless you use a hub to make it where the hub communicates with each software so that the integrations look more like this:

Number of IntegrationsLines of Communication
22
33
55
1010

If you don’t already have an integration hub, developing software will mean connecting a prohibitively large amount of lines of communication. In that case, it will be better to create an integration hub. This will take time because we’ll need to map out each point to the proper software and make sure it is developed in a way where it operates as fast as possible which means making it simple for the software to retrieve only the information it needs.

Then we have to test to make sure everything works properly. This is why we would normally do major changes one program at a time. By integrating one software at a time, you’ll get it up and running faster, be able to test the results, and then start another integration. By repeating this process til everything is integrated, you will see incremental improvements. It takes longer, but is easier to prevent and catch mistakes.

Technology Advancements

Another thing that makes development take longer than one might expect is the speed of technology advancements. New software, features, and bug fixes are released by software companies routinely. On top of that new programming languages occur to solve a need in the market. Each of these changes requires a learning curve. The developer has to figure out what is new, how it impacts the development, and the best way to implement it. This can take time especially if it is a substantial change. If it means learning a new programming language, this could take months or years.

Since no business wants to pay for that kind of a learning curve, they hire someone else who is already well versed in the programming language they need. This leads to high turnover in the software development field. While this can be mitigated somewhat by employers consistently sponsoring learning new technologies, the time it takes away a developer from accomplishing development goals can be prohibitive. In addition, problem solving is a skill that is easily transferrable to almost any field. As developers’ skill sets become less desired in the market, many that are superb at what they do choose to branch into other fields that will value their skills without the constant struggle to learn and master each new technology that comes out. Their knowledge, problem solving, and process-based mindset can be used to help organisations find opportunities for operational efficiencies. Then they just have to pass the work to developers who are well-versed in the most recent technology.

This leaves the field with less experienced veterans than many fields have. The loss of experience means that the current developers might not have seen a problem before. At that point, they have to figure out the solution.

As you can see, there are numerous factors that play into software development taking longer to develop than most people would think. At Flying Donkey, we try to limit the time to development by making incremental improvements, having group training sessions to exchange knowledge, and maintaining a staff of 30 developers with a variety of skill sets so that we can provide support on a variety of languages and tech stacks. If you’d like to discuss how we can help you improve your software, schedule a consultation.No labels