Efficiency: The Need for Speed and Robustness

In today’s world, we expect everything to run efficiently. People do not have time to lose.
One small efficiency improvement, when spread over many users, can lead to massive time and money savings. This also applies to your business applications. How much time would you and your company save if your business applications were more efficient? Probably much more than you think.
But, in what forms can efficiency express itself? Well, for starters:
How many times have we not been upset by an application that does not start fast enough on our computers or on our smartphones? When a user faces this kind of annoyance, what happens? The company who developed this piece of software suffers from a bad public image. The user loses productivity every time he starts the application. Consider real-time applications used to launch rockets and satellites; such applications have no option for any delays.
We cannot forget the famous saying, “time is money.”
Therefore applications should be time efficient.
Some applications are more critical than others. If your music player crashes often, it is annoying, but not really important. But what if your email provider is not available for multiple hours? What if your spreadsheet application crashes every time you input too much data? And what if the train control software system or air traffic monitoring system crashes? The impact of such a crash is not just annoying, it can cost the lives of thousands of people, and it must be taken very seriously.
So such applications must be robust and survive in all conditions.
Fulfilling expectations
Everyone is ready to express their expectations or, more often than not, complain. But to fulfill these expectations and avoid complaints, requires a lot of work and constant actions.
Early measurements
The first action is the measurement of the application’s quality using appropriate tools. The early measurement allows the possibility to detect defects in term of speed or robustness in the early stages of the application development lifecycle, and therefore remediate it from the beginning. An example of remediation is to review the entire architecture of the application. If these types of defects are not detected from the beginning, the changes will be impossible later.
Continuous monitoring
Once remediation is done and the application already fulfills the constraints in term of efficiency, continuous monitoring can detect other issues related to memory consumption or the use of a variable without it being initialized first. These types of issues seem, at first approach, to have small consequences, but it can end with the crashing of the entire application or a very low speed. For every type of defect found (memory consumption, performance, architecture, etc.) an appropriate remediation must be also planned.
Measurement is the key
Starting with a good level of efficiency for an application is good, keeping it there is even better. So the first step in order to keep a good level of efficiency is to do a constant measurement of quality applications using the appropriate tools to detect all the potential issues before it’s too late and the damage is already done.
As with reliability, the causes of performance inefficiency are often found in violations of good architectural and coding practice — which can be detected by measuring the static quality attributes of an application. These static attributes predict potential operational performance bottlenecks and future scalability problems, especially for applications requiring high execution speed for handling complex algorithms or huge volumes of data.
Assessing performance efficiency requires checking at least the following software engineering best practices and technical attributes:

Application architecture practices
Appropriate interactions with expensive and/or remote resources
Data access performance and data management
Memory, network, and disk space management
Coding practices
Compliance with object-oriented and structured programming best practices (as appropriate)
Compliance with SQL programming best practices

Have you had issues with efficiency in your software application development? Share your story in a comment.

Reduce Your Software’s Carbon Footprint

As you read this, thousands of data centers across the country are using up something around 1.5% of US electricity consumption. That number is projected to increase by 70% according to a recent congressional report. There’s quite a lot of coverage about software that helps manage power use when computers are not fully utilized, virtualization technology saving on hardware use, Cloud performance testing, and more recently about data center metrics like CUE and PUE.
Most of our datacenters are running IT software that supports business processes like Trading systems in financial services, Order Entry, Billing and Provisioning in telecom companies, and ERP, customer accounts, and other transactional systems that are part of any business. Many of these systems are custom developed or heavily customized by IT departments.
Sometimes this customization makes the software run more efficiently. But all too often, corners are cut and software performance problems are solved brute force by throwing more hardware at the problem. Hardware is cheap, but its carbon footprint adds up quickly.
Why is the brute force solution prevalent? More than training, the problem is time pressure. Most IT software developers are not properly trained in the software engineering techniques of optimizing performance. But even when they are, they don’t have the time to think about that as they rush to get projects done on schedule. Most managers have no way to influence their IT development organization towards writing more efficient software.
Some companies track power consumption so they can mind their PUEs and CUEs. We believe that while measuring the size of the problem is a good start, if you want to actually fix the problem it’s better to measure its source.
Over the years we’ve seen many companies, including HSBC, WellPoint, Allianz, among others, analyze the structure of their business applications and reduce hardware resource use by 10-15%. It’s even better when that analysis takes place all through development to ensure that the resulting product is always well engineered, runs efficiently, and is reliable.
Maybe instead of riding their bikes to work once a week, green-minded IT professionals should think about analyzing the structure of their biggest applications.