Steps To Figuring Out Performance Issues

Programming performance issues can be a frustrating and time-consuming problem for developers. However, tracking down these issues is a crucial step in creating software. Here are some steps that developers can take to track down programming performance issues:

The first thing to do is ALWAYS hook up a profiler to your code, reproducing your issue, and measuring what is causing it. Performance issues are often not obvious and if you don’t profile you’ll waste a bunch of time speeding up things that don’t matter(or just hide the base issue).

In my experience, here are the main areas you get performance issues:

DB
DB
DB
DB
API Calls
External Access

A little hint: most of the time you are optimizing your code and not these other areas, you are reducing readability and not significantly impacting your load times for users.

Outside of these issues, it is often something silly a developer is doing. Some of the things I’ve seen:

Pulling the whole table down(all 1 million records) then filtering on the application server
Creating new instances of classes that do a lot of work on creation instead of reusing them
Really bad exception throwing that is used as control flow
Sending down 8 megabytes of HTML for a page, of which 6 megabytes is double escaping special characters (sending ////” instead of “)

Once you figure out where the main areas of slowness, it’s time to refactor!

YAGNI – You Ain’t Gonna Need It

YAGNI and Agile

One of the hardest things to do in software development is to respect “you ain’t gonna need it” and “keep it simple stupid”. Every time I go to implement a feature, I can think of 50 extra things I should do to make it ‘complete’ and exactly what I want. It is so helpful to hit things with an Agile and iterative frame of reference. Build an MVP(minimum viable product) and publish! Extra features can come later as they are actually needed.
Recently I was working on a login page. Very simple and shouldn’t take long, right? So first I implemented the bare minimum, users with hashed passwords and a simple ‘login failed’ or setting up session and pushing to the home screen.
Then the things it should also have went through my mind.

Login pass/fail Tracking
Password resets
User unlockouts
Login with your email
Brute force alerting
Remember me
CAPTCHA
Security questions
Pretty HTML emails for various alerts
A Linux-like password storage format to allow for forwards/backwards compatibility and different algorithms
Verify timing doesn’t change for the various failure reasons(so a bad actor can’t figure out if a user exists by how long the failed password request takes)
Audit cookie security
Login with Facebook etc.
Two factor authentication

I could now spend a week setting all this up instead of building features that really bring the product forward. These are all great features, FOR LATER!

The Agile approach – small bite sized increments is great here. I wouldn’t want to give all the features to QA or the customer at the same time. It’s too much. First deliver your MVP and iterate from there. You’ll probably find out no one would have used half of the nice-to-haves that you thought would be good to have, so you can spend your time on the important stuff!

Hello!

First post!


public class HelloWorld
{
   public static void Main()
   {
      System.Console.WriteLine("Hello, World!");
   }
}