Software Engineer Productivity Vs Software Performance Vs Costs

Balancing software engineer productivity, software performance, and costs is a tricky task for any organization in the software development industry. On one hand, you want to deliver high-quality software that meets user needs, but on the other, you want to make sure you're being cost-efficient and using your resources wisely. It can be difficult to strike the right balance, especially when these factors are often in opposition to each other.

Can I have it all?

 “You can get if fast, you can have it cheap or you can get it right” Ed Yourdon

Productivity and performance can be compared to the popular playground game of the balance bar. Just as in the game, it is unlikely for both children on either end to have equal weight. Due to the force of gravity (f=m.g), the heavier child will naturally remain lower while the lighter child rises. To make the game enjoyable, both children must work together and compensate for each other's weight differences. It is a game of compromise and trade-off.

In software engineering, the same balance bar concept applies, with the addition of a third side, cost. In the same way that we have the influence of gravity on the balance bar, in the context of software engineering, we have the influence of the organization. Unfortunately, the influence is not 9.8, like the acceleration of gravity on the balance bar. Instead, it is more complex to determine, as it generally depends on the objectives of the organization, design of the teams, resources made available, stakeholders, and state of the organization, among other factors. By that, I mean that it is not something static. As an engineer, you must create a cerebral CronJob that analyzes the environment and discovers which sides of the balance bar should be prioritized.

It is very unlikely that after reading the environment, you will conclude that there is a need for balance between the three components. Even if that were the case, achieving harmony within the team responsible for the solution would be practically impossible. Pursuing the balance (perfection) can lead to excessive costs, missed deadlines, and an over-complicated solution that is difficult to maintain. Instead, it is better to focus on delivering a software solution that meets the minimum requirements, is easy to maintain, and can be improved incrementally over time.

Sometimes one goes against the other 

“Scalability is the 1st problem people don’t actually have but still solve” Eberhard Wolff

The aim to optimize without a clear understanding of the problem can be dangerous. It's like trying to extinguish a fire with gasoline — it only exacerbates the issue. This challenge becomes even more strong when members of a team hold divergent opinions on what constitutes optimization. You can have team members trying to optimize I/O performance by using faster storage or network devices, but if these devices are too fast for the rest of the system, they can actually slow it down by causing bottlenecks elsewhere. It’s like having a car with a powerful engine and wooden tires — it's worthless.

This problem is not limited to performance optimizations. Extensibility optimizations can also be dangerous. Anticipating future needs and designing overly abstract and flexible code to accommodate all potential scenarios can actually have negative consequences, including degraded performance. One particular mousetrap to watch out for is interfaces overuse, as excessive layers of abstraction can make the code harder to maintain and understand. It can also result in performance issues, due calling a method through an interface necessitates a search in the hash table data structure to determine the concrete type referenced by the interface.

The challenge arises when one designs a solution for a potential future scenario that may not materialize. What if the anticipated event does not occur? The resources invested in a forward-thinking, yet irrelevant solution, would then be wasted.

Wasting time…

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupery

You apparently optimized your code, managed to reduce response time and memory usage. Your system to process the request to the most requested endpoint is spending on average 16KB less than before (before optimization). So far, so good. Suddenly the system starts to evolve, and the function you optimized needs to change its behavior a little. Guess what? Your optimization has ruined the readability of the code, and unfortunately, you will need more time to deliver the new feature, and your company is losing time to market.

Maybe I was a bit dramatic in the paragraph above; however, what must be taken into account is that sometimes what we call optimization is just a waste of time. We have to be very critical in understanding the context. For example, for a company like Netflix that has millions of customers, reducing 11KB can generate a considerable reduction in computing costs. For a startup, it generates a super microscopic reduction, which perhaps does not even justify the complexity introduced. It’s important to consider that hardware resources are getting cheaper and faster every day. On the other hand, finding software engineers with the intellectual capacity to deal with advanced optimization algorithms is increasingly expensive, which means that in some situations, hiring and paying engineers with the ability to do super optimizations can be much more expensive than paying for resources in the cloud.

Conclusion

Software engineering involves both the exciting and challenging aspects of technology, where one hand is filled with the innovative and cutting-edge, while the other hand is filled with complex stuff.