2 added 2210 characters in body
source | link

Early during my career as a programmer, I was working on a piece of software for a bunch of my customers. I was convinced this software is the next great thing which will bring happiness to the world, so I was obviously concerned by performance.

I've heard terms such as "profiling" or "benchmark", but I didn't know what they mean and couldn't care less. Moreover, I was too focused reading the book about C, and especially the chapter where optimization techniques were discussed. When I discovered that computers perform multiplication faster than division, I replaced division by multiplication anywhere I could. When I discovered that calling a method can be slow, I combined as much methods as I could, as if the previous 100 LOC methods weren't already an issue.

Sometimes, I spent nights doing changes which, I was convinced, made difference between a slow app nobody wants, and a fast one everybody wants to download and use. The fact that two actual customers who were interested by this app requested actual features wasn't bothering me: "Who would want a feature, if the app is slow?"—I thought.

Finally, the only two customers stopped using the app. It wasn't amazingly fast despite all my efforts, mostly because when you don't know what indexes are and your app is database-intensive, there is something wrong. Anyway, when I was doing just another performance-related change, which was improving by a few microseconds the execution of code which is used once per month, customers didn't see changes. What they were seeing is that user experience is terrible, documentation is missing, crucial features they were requesting for months were not here and the number of bugs to solve was constantly growing.

Result: I hoped this app will be used by thousands of companies around the world, but today, you won't find any information about this application on the internet. The only two customers abandoned it, and the project was abandoned as well. It was never marketed, never publicly advertised, and today, I'm not even sure I can compile it on my PC (nor find the original sources). This wouldn't have happened if I was focusing more on things that actually matter.

Early during my career as a programmer, I was working on a piece of software for a bunch of my customers. I was convinced this software is the next great thing which will bring happiness to the world, so I was obviously concerned by performance.

I've heard terms such as "profiling" or "benchmark", but I didn't know what they mean and couldn't care less. Moreover, I was too focused reading the book about C, and especially the chapter where optimization techniques were discussed. When I discovered that computers perform multiplication faster than division, I replaced division by multiplication anywhere I could. When I discovered that calling a method can be slow, I combined as much methods as I could, as if the previous 100 LOC methods weren't already an issue.

Sometimes, I spent nights doing changes which, I was convinced, made difference between a slow app nobody wants, and a fast one everybody wants to download and use. The fact that two actual customers who were interested by this app requested actual features wasn't bothering me: "Who would want a feature, if the app is slow?"—I thought.

Finally, the only two customers stopped using the app. It wasn't amazingly fast despite all my efforts, mostly because when you don't know what indexes are and your app is database-intensive, there is something wrong. Anyway, when I was doing just another performance-related change, which was improving by a few microseconds the execution of code which is used once per month, customers didn't see changes. What they were seeing is that user experience is terrible, documentation is missing, crucial features they were requesting for months were not here and the number of bugs to solve was constantly growing.

Result: I hoped this app will be used by thousands of companies around the world, but today, you won't find any information about this application on the internet. The only two customers abandoned it, and the project was abandoned as well. It was never marketed, never publicly advertised, and today, I'm not even sure I can compile it on my PC (nor find the original sources). This wouldn't have happened if I was focusing more on things that actually matter.

1
source | link

You're right, performance in business apps is not really an important subject the way it is discussed by most programmers. Usually, performance-related discussions I hear from programmers have several issues:

  • They are mostly premature optimization. Usually, someone wants "the fastest way" to do an operation with no apparent reason, and ends up either making code changes which are made by most compilers anyway (such as replacing division by multiplication or inlining a method), or spending days making changes which will help gaining a few microseconds at runtime.

  • They are often speculative. I'm glad to see that on Stack Overflow and Programmers.SE, profiling is mentioned frequently when the question is related to performance, but I'm also disappointed when I see two programmers who don't know what profiling are discussing about performance-related changes they should do in their code. They believe the changes will make everything faster, but practically every time, it will either have no visible effect or slow the things down, while a profiler would have pointed them to another part of the code which can easily be optimized and which wastes 80% of the time.

  • They are focused on technical aspects only. Performance of user-oriented applications is about the feeling: does it feel fast and responsive, or does it feel slow and clunky? In this context, performance problems are usually solved much better by user experience designers: a simple animated transition may often be the difference between an app which feels terribly slow and the app which feels responsive, while both spend 600 ms. doing the operation.

  • They are based on subjective elements even when they are related to technical constraints. If it's not the question of feeling fast and responsive, there should be a non-functional requirement which specifies how fast an operation should be performed on specific data, running on specific system. In reality, it happens more like that: the manager tells that he finds something slow, and then, developers need to figure out what does that mean. Is it slow like in "it should be below 30 ms. while currently, it wastes ten seconds", or slow like "we can maybe lower the duration from ten to nine seconds"?

This being said, performance in general is important:

  • In non-business apps, it can become crucial. There is embedded software, software ran on servers (when you have a few thousand of requests per second, which is not that big, performance starts to be a concern), software ran on smartphones, video games, software for professionals (try to handle a 50 GB file in Photoshop on a not very fast machine to be convinced) and even ordinary software products which are sold to lots of people (if Microsoft Word spends twice its time to do every operation it does, the time lost multiplied by the number of users will become an issue).

  • In business apps, there are many cases where an application which feels and is slow will be hated by the users. You don't want that, making performance on of your concerns.