Quality

I had a recent epiphany at work.  I was asked why I feel compelled to dig into other people’s code and make them do things my way.  A fair question.

First, let me start with a little background.  In my career, I have been brought into several projects where a ninja was needed.  The program code was performing poorly or it had errors, or it was just generally difficult to maintain.  I love those projects because the requirements are so easy.  I fix-up the program and walk away a hero.  It feels awesome!  However, I feel bad for the people who wrote the original product because they put-in 99% of the hard work and were rewarded by criticism and derision.

Each of these projects had a single thing in common:  the programs were poorly written.  You might not realize it from looking at the code.  In fact, some of them seemed very complex and eloquent, using the most cutting-edge features of the technology.  You might look at the code and scratch your head saying “dang, this must be really good because I don’t understand what it is doing”.

It is a little funny because contractors have a solid reputation for delivering un-maintainable projects.  This is because contractors are usually responsible for one thing: get this project done as quickly and cheap as possible.  So they are encouraged to cut corners and are rewarded for doing so.  Then, they leave and never have to maintain their programs.  So, they rarely see any repercussions from delivering poor quality.  Worse than that, they probably don’t get to learn from their mistakes.

In contrast, if you get stuck doing maintenance programming, you see the cost of poor quality, all of the time.  One of my favorite questions to ask interviewees is about lessons that they may have learned from maintaining other people’s code.  If they quickly rattle-off a half dozen things, then I have a winner.  If they can’t think of any, then I need to worry, because that person will need lots of mentoring and supervision.  The more experience that person has (in building low-quality software), the more of a fight I will have on my hands as I work with them to break their bad habits and use better ones.  It feels like thankless work and it is exhausting. 

The really ironic thing about delivering good quality, is that it doesn’t usually add any additional time to a project, once you know the difference.  Therein lies the problem.  Most people have no idea how to tell the difference.  You only seem to see the side-effects months or years after the project is done.

This is the value that an experienced developer adds to a project.  I would assert that every developer should, on his own honor, strive to deliver good quality programs and should be passionate about it.  He should also constantly be questioning his own techniques and seeking ways of improving what he is doing.  It is also ironic how many experienced developers don’t work on improving these types of skills.  They will hit you with “I have more experience than you, so my opinion should automatically be more valuable than yours”.  I hate that kind of talk.  Here is your red herring back, sir.

Being really-good doesn’t mean being closed-minded or ego-centric.  Quite the opposite.  To get better, you need to open your mind and consider other approaches.  Be ready to argue your point, but be willing to concede.  

More than that, the question you should ask is, “when should I use this approach/technology/pattern and when should I not use it“.  If the answer ever comes back “always” or “never”, then you probably don’t really understand what you are talking about and you should not speak up until you do.  You owe it to your co-workers and your employer and to yourself, to know when you should use a technology and when you should NOT.  And you should be able to explain why, without saying something like “well, it is what everyone is doing” or “it is an industry standard” or “that is what the book says”.  Yes, of course, but why?!  It is like saying “drinking water is always good for you”, but you don’t realize that sometimes, people die from drinking water.  Seriously.  Go look it up.  So, even simple stuff like that is not a good idea all of the time.  Neither are industry standards and stuff that is written in a book.

So, if I argue with you occasionally, please try to see it as a complement, because I am assuming that you are smart and are able to speak intelligently about a topic.  On the other hand, if I get frustrated and walk away, keep in mind that we both just lost an opportunity to learn something and improve ourselves.

Advertisements

About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Architecture. Bookmark the permalink.

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