Eye opener: developers spend more than half their time fixing performance issues instead of innovating

You can innovate at least twice as fast

Hey IT manager, how much time do your developers spend fighting fires? A recent survey by Cisco shows that developers spend 57% of their time fighting fires and being pulled into war rooms rather than creating new software that makes the cash register sing. In other words, they could be 133% more productive on innovation if they where not so busy solving issues. The question arises: How fast can you grow if your innovation speed doubles?

Developers are only trained to fix issues, not find them

It appears that developers have trouble finding the root cause of performance issues. Why? The answer is simple: They're not trained for this. If your walls start showing cracks, you hire a building inspector to find the issue. Then, after the diagnosis, you hire a contractor to fix it. In IT we expect the contractor to both the finding and the fixing. And that is the often overlooked problem: it's the finding of the causes that programmers waste a lot of their time on.

Finding the root cause

So ... You think you have the root cause? Right? Or is the problem even bigger? Just hire a specialized resource and ... Ready? The root cause can be a lack of resources, but just as often it's not. More often it's in:

Bad usage of networks
Bad usage of databases
Latency issues
Bad configurations
People suddenly working from home in large numbers
Not using all available resources
...

We've seen them all and then some.

Bottom line: You can't start fixing the issue until you know the root cause. So you want the root cause found fast. Many root causes are not even visible to developers, yet they are expected to find and solve them.

Even if the issue is an apparent lack of resources, adding CPU, memory or disk only gets you so far. Hardware and cloud resources become progressively more expensive with increasing speed. At some point you need to upgrade to a more expensive database license...

Improving the efficiency and scalability (see below) of the software pays off quickly from a certain point.

If software is not growing, it's dying!

Why are the developers not to blame? For many reasons! You may ask yourself ... But the software did not change? No, but the environment it runs in did. Or A new version of Windows, Or a new version of the database, network changes, different storage, different hardware, ... All these things are happening continuously and often outside the awareness of the developers. Some of these changes have a major impact.

Although we like to think of our IT colleagues as magicians (and more often than not they are), they do not have X-Ray eyes that see every single change in their surroundings. We have to help them understand.

An example was the upgrade from SQL Server 2012 to SQL Server 2014. Many applications had a major performance drop after the upgrade often at unpredictable moments. The cause was a major change in the optimizer and in the way statistics are generated. The performance drop could have been avoided, the change in 2014 was announced long before 2014 was released for production. But developers generally don’t read the release notes for a new database server version and even if they do, they mostly don’t grasp the consequences.

This is just ONE example of the many stories I can share about this. Issues like this happen frequently, caused by changes in the environment the application uses.

If your software does not adapt to the ever changing world around it will degrade over time. At some point grind to a halt altogether. You need to make sure you're growing and not dying.

Optimizing for the right scale is essential

Hundreds of books have been written about scaling a software development organization, and you've probably read many. But do you know scaling the actual software is just as important? Honestly, probably more.

Do you know what it takes to scale the software you deliver? Not scaling well has many causes, let me list a few: Many performance issues show when software needs to scale to a bigger organization. Whether it's growth of an existing customer or a new customer that's much bigger than the ones you've served in the past. Or when your software moves from many smaller deployments on prem to a single large instance in a SAAS environment. Any significant scale change requires software to adapt.

Take an example from the physical world: 200 single family homes can't be cobbled together to make a skyscraper. You can't build a skyscraper out of wood, the way many single family homes in North America are built. Software is no different. When it comes to scaling you need to think and design on a different scale and choose a different approach.

You need insights, not observability

Beauty is in the eye of the beholder. And so are many other things. In this blog I explain why having APM or observability tooling does not bring you insights. Insight that you need to quickly find what YOU need to fix and how. So your developers can implement the fixes well planned, structured and fast so they can get back to the innovation that brings you and your customers value.

Oversight is crucial

Most IT people are specialists these days. They know everything about something. That's a must-have but with the complexity of today's application landscapes you're missing the people who know something about everything. The people that can connect the dots. When each specialist looks at their own specialty things get missed. You need a helicopter view in your IT organization.

At a customer of ours the storage network was considered network by the storage specialists. And storage by the network specialists. I'll give you 1 guess where the problem was. ;-)

You have prevention, don't you?

Proactive is a buzzword in APM and observability. And we're in dire need of proactivity. Proactivity requires something else on top of installing a tool and setting thresholds that trigger alarms . Being proactive about performance requires that you look regularly, analyze outliers and trends and act on the outcomes so problems don't become problematic. And test new versions of the application and the application environment before moving them to production. Waiting for the alarms to go off and then breaking out the fire hoses is just reactive, even if some tool is 'actively' looking for you.

Stop fighting fires, start innovating!

Getting outside help is essential if you want your programmers to make you money with fresh innovation that sets you apart from the competition. That boosts your growth.

When we work with our customers we find their issues fast. We have a 100% score. Our record is 15 minutes after we started measuring . We deliver actionable insight that allow our customers to implementing fixes quickly and move on to innovation. This is what one of our customers said: “Especially in busy periods several applications would stall, causing frustration for employees. Just when we needed financial reports servers would grind to a halt. Our system administrators were aware of the problems and did what they could. They increased internal memory a step at a time but the problems came back every time. After a while they too were out of options. I got in touch with Sciante and made an appointment”.

Make a 15 minute appointment now and find out how you transform your developers from fire fighters to innovators. Click here to make the appointment.