Alex Bunardzic’s Post

View profile for Alex Bunardzic, graphic

Software development/delivery expert for hire

If we build and release an app, and we notice that the performance is sluggish, we should profile that app and benchmark its performance. It's akin to doing an x-ray on a patient, plus maybe doing some lab analysis (blood, urine, whathaveyou). That practice should help us identify the bottleneck(s). In my experience, most of the time the culprit for suboptimal performance is found at the I/O boundary. That bottleneck is relatively easy to identify. Once identified, the team should work on removing the bottleneck. But if the team hasn't identified the bottleneck, there is a risk of them wasting time, money, and effort on optimizing imaginary bottlenecks. Most typically, from what I see, teams may jump on working on optimizing the code, tightening the performance of the code that runs in main memory. What a waste! No matter how much we improve the performance of the code, the app will remain as sluggish as it was before we wasted so much time, money, and effort on trying to fix it. The real bottleneck is still there. Similar considerations apply to the team's work style. If the delivery to production is sluggish, no use trying to invent ways for the team to write the code faster, unless we have proven that the bottleneck is indeed in the speed of typing. But I see teams arguing against some new ways of working (mob programming, for example) saying that it is slowing the rate of pumping code into the feature branch. Even if that were true, who cares? Just bloating the feature branch with more and more code is the exact opposite of productivity. Do teams realize that productivity only means putting solutions in the hands of end users/customers? So, where is the real bottleneck that is causing teams to falter and delay the production of solutions? I'd wager to say it's never in the speed of writing the code.

To view or add a comment, sign in

Explore topics