WTF Per Minute - An Actual Measurement for Code Quality

    Cars have MPH (Miles per Hour) that measures the speed that they travel. The better the car the faster the MPH or speed. Developers have WTFPM (WTF per Minute) that measures the number of ‘Works That Frustrate’ that the developer can read per minute, aka code quality. And just like cars, the better the developer the more WTFPM they can attain. Here is where they differ however. With a car, the BETTER the road the more MPH it can attain. With a developer, the WORSE the code the more WTFPM can be obtained.

Signs that a developer is increasing their WTFPM can include but is not limited to:

1. A rumbling sound as they start to audibly growl at the code they are reading.
2. A reddening of the face as their temper gets hotter and hotter.
3. A whiting of the knuckles as they grip onto the mouse to keep from losing control of their WTFPM. 

Warning: A overly high WTFPM can result in the following:

1. Desk Flipping
2. Rage Coding as offending code is completely re-written (with or without a PBI/Task)
3. In the most serious of cases, Rage Quitting for the day/week/month/year/lifetime 

Activities that can control the WTFPM in the workplace:

1. Code Reviews - These allow for a controlled WTFPM increase while also addressing the offending code. Due to the small amount of code being reviewed at any given time the WTFPM should be relatively small and controllable.
2. Shop Standards and adherence to them - Look at this like a global WTFPM governor. If these are adhered to the WTFPM should remain manageable.
3. 'Ongoing Education' and 'Learning from Your Mistakes' - This power duo should lower the WTFPM attained by other developers reading your code, because you never know if the developer reading your code will be a violent psychopath who knows where you live.

//Comments

Comments come in two forms, bad and less bad. Comments and whether to use/leave them in code can be one of the more passionate discussions you can have with a developer. I say this because there are those that think all comments are bad and there are those that have valid reasons for leaving them. I fall somewhere in the middle. For the most part I see comments as bad. Most of what I have seen with comments can be replaced with cleaner, more descriptive code or removed entirely as they are no longer relevant and were never maintained. And, thanks to refactoring tools like ReSharper may not even be related to the code around them. There are some occasions that they are less bad. These are the rare situations where the code and related comment might actually remain together and be relevant. I have only seen this in situations where newer applications are tying into legacy applications and a bit of explanation is needed to explain why mapping Response Name to Response Type Name totally makes since. Special comments such as //TODO and //BUG are still bad comments to have. When I see these in code the first thing I look for is a task related to them in whatever tracking system we are using. Without a task TO DO things or fix that BUG then these are just lost on the code.