Call us Toll-Free:
Email us


Three different ways of handling a problem

Mike Peters, 10-25-2010
Presented with a new problem, I noticed engineers can be divided to three groups:

1. I don't know, don't understand, not familiar with this part of the code

Unless you're on your first few weeks with the company, this statement is totally inexcusable. It's lazy and pathetic.

Be a Problem solver.

Waving your hands in the air announcing to the world you're not familiar with some code, does nothing more than exhibit your incompetence in picking up something new and running with it.

How comfortable will your manager, peers and clients feel, once you've made such a statement?

Be a Problem solver. Study the code, follow the execution process flow, find engineers who are more familiar than you and ask them specific questions.

Don't stop probing and asking until you've mastered the code.

Unless you fully understand the code, problem at hand and the big picture implications, you're better off not touching it at all.

2. Quick and dirty: Let me patch it up real nice. In & out as quickly as possible.

Time is of the essence, right?

How about doing the absolute minimum, so the problem can be patched up and you can move on with more important pressing items on your todo list?


I'm a big proponent of code clarity and elegance.

Taking shortcuts, especially when working in an agile development environment, will come back to bite you in the butt.

Why I hate patches:

* Patches clutter the code, which means the next guy will have to struggle twice as hard to understand what's going on

* Patches are often specific to dealing with one edge case, one facet of the problem. Slightly different variation of the same problem and you're back to square one.

* Patching up code is often a lazy act done by someone who didn't want to take the time to understand the big picture. Which means, chances are the patch can break other perfectly valid scenarios.

Take the time to do things right, the first time around.

The difference between patching up a problem and doing it right? That brings me to the third type of engineers, those who still have a job.

3. The right way: Complete, Elegant and Short

How do you know when you've fully mastered a problem and came up with the best possible solution?

Think Occam's Razor

* When your solution is clean, simple and easy to understand;
* When you cannot make it any better had you had unlimited time on your hands;
* When your solution doesn't handle a single edge case of the problem, but rather completely eliminate it;
* When you feel your code should go up on the code hall of fame;

...that's when you're a real code ninja.

Be careful though. It's very easy to take this the way of over-engineering things.

If you're adding complexity instead of taking things away and simplyfing, you're doing it all wrong.

This doesn't mean you should re-engineer an entire architecture from scratch, only to make things cleaner.

It's okay to take baby steps, just make sure your contribution to the code, is the single most Elegant, Complete and Short solution.


A simple example

MySQL database server used to store timestamps in this format:

For example, 7am October 25th, 2010, would be represented as: 20101025070000

Starting with MySQL 5.1, the way timestamps are represented in the database changed to: YYYY-MM-DD HH:II:SS

The same date, is now represented as: 2010-10-25 07:00:00

When no date is set, MySQL 5.1 used 0000-00-00 00:00:00 whereas previous versions of the MySQL database used 00000000000000.

A few sections of our code had to test whether or not a timestamp was set.

The original php code looked something like this:

// If no timestamp
if ($timestamp=="00000000000000")
// Do something

With the transition to MySQL 5.1, a new problem surfaced, where new records used "0000-00-00 00:00:00" to indicate no date was set, while old denormalized data still used "00000000000000".

Three different engineers approached this simple problem of supporting both the old and new timestamp formats.

I've included an excerpt of what each had to say below.

Engineer 1:
I'm not too familiar with MySQL 5.1, but I don't think we can support the old timestamps any more.

Engineer 2:
Fixed! And it only took a minute to do.

I'm now testing for both cases:

// If no timestamp
if ($timestamp=="00000000000000" || $timestamp=="0000-00-00 00:00:00")

Engineer 3:
To keep the code clean, handle other cases (where we have 0000-00-00 with no hour/minute/second) and make it easy to adjust in the future, I created a new function IsEmptyTimestamp() and updated the code accordingly:

// If no timestamp
if (IsEmptyTimestamp($timestamp))

* First guy is out.

* Second guy cluttered the code, didn't properly handle other edge cases and didn't think about the future.

* Third one passed with flying colors.

Closing Thoughts

When I originally wrote this piece, I was thinking software development.

I realize now, after reading this again, that the same traits described here, apply to any area in business.

Be a true Problem solver.

It's the single most important skill you'll ever develop.

Chris G, 10-26-2010
How about those who do:

if (strtotime($timestamp))

Cat4/133t? ;)

Dawn Rossi, 10-26-2010
Chris, strtotime is not the most efficient way to check if a timestamp is "empty"
Enjoyed this post?

Subscribe Now to receive new posts via Email as soon as they come out.

Post your comments

Note: No link spamming! If your message contains link/s, it will NOT be published on the site before manually approved by one of our moderators.

About Us  |  Contact us  |  Privacy Policy  |  Terms & Conditions