Bad Developer, No Twinkie Part 8: Not paying attention to performance

Those of you who do graphics programming for games already know this.  Move along  The rest of you: feel free to pay attention.

You need to pay attention to performance.*

Numerous times, I’ve seen someone say something along the lines of ‘Well, it worked well enough with 10 records.  I didn’t test it with 100,000.’  Far too often we don’t pay any attention to performance, and it comes around to bite us in the butt.  We test with small data sets, and we expect the same performance when working with 10x or 100x as much data.

Thinking about a fairly recent project I worked on, a particular part of the website worked fine for testing purposes with a few records.  When given 20 or so records, a particular feature of the site slowed right down, and became somewhat frustrating to the users.  Rather than being able to immediately click on a record to see the details of that record, the user would instead have to wait several seconds – even after the initial list of records was displayed – before a particular UI element became enabled (which allows the user to see the details of the record).  This was in production.  How did it get into production with terrible performance?

  1. It was rushed, and never tested properly.
  2. It was never tested with a data set larger than 5 records.
  3. It suffered from poor communication between the UI team and the back-end team.

* Except When You Don’t.

Like anything else, there are exceptions to this.  Premature optimization is the root of all evil.  Remember the order:

  1. Make it.
  2. Make it work.
  3. Make it work right.
  4. Make it work right, fast.

There’s a difference between premature optimization and being downright sloppy and not planning for the future. Saving a single allocation in a for loop is premature optimization. Knowing that a particular feature is going to have to run “fast” on 100,000 pieces of data is a whole other thing. This is where it helps to have performance hammered out as part of the requirements. “Needs to do x in less than y seconds” makes it possible to say “Yes, this passes” or “No, this is too slow”.

I always wonder about the guys who write installers.  When running an installer, it seems like half the time my machine isn’t taxed by CPU, memory, disk usage, or bandwidth limitations.  If it isn’t doing any of those things, what the heck is it doing?  Where’s the bottleneck?  I understand that having a fast installer isn’t a high priority for a lot of people, but if it’s your job to write installers, it ought to be a priority.  You’ve only done 3 out of 4 of the above list.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s