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. Yesterday 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.

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.

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 to use C, after all I was studying it at the Uni.

At the same time, 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. It will be even better for my grades in the future tests."

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.

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

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

Nowadays, I see people putting too much effort in new technologies, new methodologies and focusing too much about performance where is not really needed. use datasets or use MVC? Use an array list or a generic list? That’s something like over-engineering an application. IMHO, this can lead to complex and expensive systems to maintain.

So, lessons 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 with the most critical parts.

Be sure of that: Not even Jesus pleased everyone. At the end it does not matter how effort you placed in the application or how cool you did that module using a new logical path there is always people telling you it could be done better.

That's software, that's simple and 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?

No Comments