The Economics of Software Performance

It does not matter the current state in which an application is, everyone always wants a bigger, better and faster version. One of these days, when talking to my peers we discussed this point: If you have to choose amongst these items, which one would you leave for last? I said performance.

Just hold your thought for a minute and bear with me on this before throwing stones ok? I’ll explain.

 

My point is: To design for high performance is expensive and, on these times of ROI, is a good thing to save some $$$ for when we need it most. I am not saying “don’t do it”; I’m saying “do it later”.

In my first job about a decade ago, I had to work with protocols and microchip programming. In one of those projects I had to implement a little protocol to communicate 2 heaters. I asked my manager to use C, after all I was studying it at the Uni.

 

Back then, there was a group of cool people programming in Assembly and these guys told me to give Assembly a try…for performance reasons. I told them:"Guys, I do not have experience with this and I prefer to use C. ( and It was even going to help me with my grades.)"

 

Truth must be said: the prototype was done and indeed it was too slow. Way too slow!

 

It was during my young years and I still remember all the comments I've heard about this bad performance. Those comments just fired me up! I was in a mission now to prove them wrong. (you know how young guns are…)

So, I asked for more time, and with more 2 friends we debugged the code. We discovered that we were wasting too much time during the handshake. That's it! we found the bottleneck!

 

So we implemented just that handshake part in Assembly.

After some fine tuning: the application was now too fast! Win-Win!

 

Nowadays, I see people putting too much effort in new technologies, new methodologies and focusing too much about performance where is not really needed: To use datasets or MVC? an array list or a generic list? Sometimes people over-engineering an application. IMHO, this sort of thinking is OK but, once let it loose, it can lead to complex and expensive systems to maintain.

 

So, lessons I learned from this situation:

First, make sure you have freedom to use your skills in the area you know most: Sometimes we are forced to follow an already designed specification and there is not much freedom for our own ideas. The project priorities supersede our own priorities. If you have this ability then...

 

Second, do proof of concepts: When you find a proof that is modular enough to detach and that works good enough above the average, move on to the next module...and then...

Focus the effort in time and money in the most critical parts: Be sure of that; not even Jesus pleased everyone (leaving religious discussions apart) so you also won’t please everyone. And that’s OK! At the end of the day, most the times it does not matter how much effort you placed in the application or how cool you did that module using a new algorithmic path…. there will be always people telling you it could be done better, faster.

 

That's software, that's simple and you know what? that's life

but hey, these are the sort of comments that makes you want to be better, to improve and move stronger ahead, aren't they?

By Edge Pereira