Among developers, there's a behavior that is more damaging than guessing. Because we're trained to look at code, when something goes wrong, we look at code. And no matter how good our code is, we can always find something wrong or ugly that's begging to be fixed...
Finding ugly code will throw even the best developers off track— because the code is ugly, they will guess that it's the source of the problem. So developers often fix things that have little or no impact on overall performance. I've seen teams literally waste months rewriting ugly code that had no impact on performance...
I'm not saying it's wrong to look into the code. Typically, that's exactly what we'll have to do. But we should delay looking at the code until we have a solid measurement or clue as to exactly which part of our application is responsible for the problem. It's amazing how, when developers are armed with a good measurement, they suddenly start looking past the ugly bits...
Pepperdine also talks about the importance of writing simple, straightforward code, as opposed to relying on clever-looking optimizations:
While we write code to run on a machine, the primary consumers of code are humans. Dumb code tends to be more readable and hence more understandable. If we can iron out the twists, then we have a better chance of avoiding the dumb mistakes that clever code may hide from us... HotSpot, IBM's MMI, and the JIT are tools that work to optimize our code for us through dynamic profiling. Complex code tends to confuse these tools, so that they provide either suboptimal optimizations or no optimizations at all.
Another reason to write dumb code is that most of the complexities are due to some optimization that everyone thinks is needed. In many cases, these optimizations are premature. While I'm all for performance planning, I'm dead set against premature optimizations. When is a plan a plan, and when is it premature? I guess it's a little like the difference between art and porn: You'll know it when you see it...
What do you think about Pepperdine's comments concerning the relationship between ugly code and performance bottlenecks?
I think this is not a correct perspective. Why do we have bad code in the system? Of course, developers do write bad code (everybody does) but such assumption, that "bad code is OK" I think is somewhat dangerous.
That said, <i>every</i> optimization should be done after measurement. Just start working - no matter if it is a code refactoring, or purchasing a system upgrade - without any analysis upfront is quite a good way for failure.
I think you picked out the worst quotes from the whole article. I don't like the advice to write dumb code. Where I work, I came up with a really smart algorithm, but I wasn't sure if my coworkers would understand it, so I am planning to use a code review session to train everybody in how it works. I'd rather keep my smart algorithm than go back to the eight times more wordier version I had before.
Here is, in my humble opinion, the best advice in the article:
----- A product company I worked for frequently sent me to their more difficult customers. I assumed it was some sort of punishment for something I'd done. I asked the sales guy what was up with that. He said, "Hey, I send you to noisy customers, and when you leave, they're no longer noisy."
What I'd discovered very early on is that the customers were often frustrated. They had tight deadlines, aggressive plans, and intense pressure to deliver -- and no matter what they did, things just didn't seem to be working. To make things worse, they "knew" the problem wasn't their fault. I let them rant and rave and in the process vent their frustration. What happened is they ended up explaining exactly what was wrong with the system. So it both allowed them to vent and I could parrot back what they told me in the form of a diagnosis. They got to release all of their stress, and I ended up looking brilliant.
I quickly learned that the more frustrated the customer, the more brilliant I was going to appear to be, which may sound a bit egotistical, but honestly, most of the teams I was helping were cleverer than I could ever hope to be. The only advantage I had was that I'd learned to turn frustration and stress into something useful.
Stress prevents us from learning. The first thing I look for in an SOS engagement is a pressure-relief valve, some hack or trick to reduce the level of stress in the room. -----
I find this to be the hardest part of the job, and the one thing that my co-workers complain the most about having to deal with.
Previous Topic
