My Program is Choking! Bottlenecks in software development.

By Daniel Goldman | The B.C.U. Times | 19 Sep 2019

"Smart contracts" or distributed and decentralized programs (DDPs) are simply very different than traditional programs, and programmers need to be careful about using traditional design practices, or it can be very costly.

I remember one semester, fairly early in my computer science program, I started to become very interested in calculating how many operations my functions were actually requiring. The professor told me not to worry about it, and just focus on their limiting behavior (Big O value). In most software development applications, it’s all that really matters. If a function scales linearly O(n), then a company can just throw in more computing power and scale their systems linearly. 

The Issue

This method is reasonable for traditional programming operations, as computer hardware is relatively cheap. The major bottleneck in cost, for these types of applications, is the fees paid to develop the software. Human labor is, after all, quite expensive. I’m not sure how common it was, or still is, to ignore deeper inspection in order to identify how many actual operations are being executed. But I finished my associates in Computer Science in 2005, and back then, it didn’t really matter too much.

But times have changed. Indeed, a few years after I finished my program, Bitcoin was developed. And a few years after that, Ethereum and the ability to create distributed and decentralized contracts/programs (DDC/DDP) emerged. For these types of programs, there is a cost to each operation, and it is not trivial. The bottleneck in cost for these types of programs is the number of operations being executed, not the software development costs. And so now, software engineers have to learn to identify more than just the limiting behavior of their functions. They have to pay close attention to the actual number of operations their functions perform. And often times, there is a long term payoff in using more complicated software engineering techniques, because it significantly decreases the operating costs of the contract, even if it means taking a significantly larger amount of time writing code.


I always have trouble coming up with a simple example. Consider the following. We want to take an array of values, after converting them to a different set of units. The conversion rate is 1,000 units of A for every 200 units of B. To make the operation clear, the multiplication and division is left alone. 

uint sum = 0;

for (uint i = 0; i < n; i++) {sum += val[i] * 200 / 1000;}

This function is fine, for a traditional program. Cleaner programs are easier to maintain, and so they're less costly to produce. However, division is a complicated operation, and in blockchain applications, it can be rather costly. Ethereum charges the same amount of gas for multiplication and division and they have a gas price of 5 gas, which is about 67% more expensive than an addition operation. It's not the most expensive operation, but it's definitely expensive. Now, the for loop is O(n), and if we simply replaced val[i] * 200 / 1000, with val[i] / 5, we would save 5 gas per iteration, or 5n gas. That's significant! How significant depends on the current price of gas. 


While this example is a simple one, there are far more complex instances where an attempt to efficiently write and maintain code may lead to incredibly expensive contracts. I wonder if software engineering programs are starting to take these ideas into consideration. I wonder if other programs, outside of the one that I took, already consider these factors. There are various software profiling packages, which can help. But for so many years, there has been little need to focus on maximizing efficiency in such a way, because it was simply too labor intensive. The very art of programming is simply different for traditional programs and DDPs, so even though blockchain developers should not ignore the theoretical foundations of software development that has grown over the many years, these developers also need to understand that there are significant differences, when it comes to best design practices. 

Photo by Chris Ried on Unsplash

How do you rate this article?



Daniel Goldman
Daniel Goldman

I’m a polymath and a rōnin scholar. That is to say that I enjoy studying many different topics. Find more at

The B.C.U. Times
The B.C.U. Times

The B.C.U. Times - blog about promoting the blockchain and cryptoasset user experience and ecosystem.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.