Rules of software optimization

“Rules of Optimization:

Rule 1: Don't do it.

Rule 2 (for experts only): Don't do it yet. ” 

- Michael A. Jackson

The presenter talked about processing TBs of data in less and less time, even as models get more complicated. Slides covered different communication options, kinds of multithreading, benchmarks measuring time and memory foot-print for massively parallel processing. Chip capabilities and layout, high-speed interconnects, highly-specialized libraries and compiler options to take the best advantage of the available hardware.

Dealing with complex models on large data sets available all at the same time is a serious and very interesting problem.  Modern computers are immensely powerful, with a typical laptop packing multiple cores, popular languages and compilers doing a great job of optimization, and many high-performance tools widely available for learning and using. Yet most of existing and in-progress software only uses a tiny fraction of available horsepower, and the vast majority of developers are not aware of the vast amount of work their systems are capable of handling, with the right setup.

This is a fine state of things.

Optimizing performance comes at a cost. This cost can be time – it takes time to assess performance, find bottlenecks, and do something about them. This cost can be money – it takes a better-educated developer to measure and reason about performance, and what it should be. Most often, this cost also comes in correctness – optimizing code is tricky, and bugs can and will be introduced while chasing speed. The hard-core performance optimization, to take the best advantage of the available hardware and software, can make code longer and more complex, less readable and maintainable.

However, there is an even bigger reason why getting the best performance is only relevant in a narrow set of applications. A typical business application today is interactive, works with live user input, and produces output for human consumption in real time. Once output is produced fast-enough, there is no value in producing it any faster.  If showing a document on the screen takes 200msec, doing it any faster has no value.  

It is best to leave the performance optimization for the applications and scenarios that will deliver better value because of the speed. For the rest of modern software development, it is better to concentrate on correctness, maintainability, and making code as simple as possible.

What does it mean to do a good job?

I am lucky to know many hard-working, dedicated, well-meaning people who like their jobs, greatly enjoy what they do, and care a great deal to do good work.  Yet, the idea of different people of what it means to do good work can vary tremendously.   

There is a career-driven definition of doing good work. Good work is work that gets the person to the next step of their desired career path. It usually translates into doing what the boss wants to get done, exactly the way the boss wants it done. Occasionally it means doing the things that get noticed by the decision makers, and little or nothing else.

Particular definition of ‘doing good work’ in this case can vary slowly over time, as bosses, their opinions, and the person’s understanding of bosses’ opinions change. 

Another approach to defining what it means to do a good job is a craftsman’s definition. Technical quality of individual’s work is measured against expectations set by an independently defined standard, unconnected to the organization. 

In this scenario, what it means to do good work can vary quickly or slowly, depending on the chosen base standard and its rate of change. Unfortunately, the changes in the standard can, and is likely to, inspire changes that are unconnected to the practical needs.

Finally, there is a value-driven definition to doing a good job. Is the work being done gets the organization the most benefit toward its vision and goals? Then it’s excellent work. The trouble with attempting to do good work by this definition is that organization's true vision and goals are often not known to many workers. Honest and comprehensive communication of the organization's vision and goals are very hard, and rare in large organizations.

Good job under value-driven definition can and does change, as goals change, or perhaps goal perception changes. It can be very frustrating, though, when goals, or available information about goals, change frequently and in contradicting ways.

What is your idea of what it means to be 'doing good work'?  Is it different from your bosses’, or your organizations? Have you changed your understanding of what it means to do a good job in your career? 

No fighting in the war room

“I will stand up against development to fight for software quality!” – said a perspective QA manager. She was smiling, but in way that left no doubt – she meant every word, and she was good at fighting and winning against bad things and bad people.

As a developer, I liked the candidate’s strong stand on quality, but was not sure why we should be fighting. The QA was a part of Dev organization, and a new QA manager was going to report to Dev manager. After the interview, we discussed how our Dev team works with our QA organization, cooperating and helping each other. We all had a common goal of producing high-quality product, and fighting was nobody’s idea of fun, nor was it helpful in achieving this goal.  

As it turned out, our team was both lucky and smart, creating and maintaining a helping and cooperative spirit in the office. As we learnt through talking to this and other QA manager candidates, there were plenty of companies where testers fought against developers. QA groups won by finding enough quality issues with the product to prevent delivery.  Developers won by getting the product delivered, despite known problems.  A strong development group put a QA team at a disadvantage, while a thorough testing created problems for the developers. Which makes no sense, because having great people and organizations in both Dev and QA should make everyone's lives better, not worse.

As satisfying as winning is, it is important to keep in mind the overall goals of the organization. In IT and software development, it is usually creating and delivering a quality product for the customer.  Nobody wins if the product is not tested properly, is of poor quality, nor if the product is not released to the user. Everybody wins if QA and Development (and the rest of the organization) work together.