AJ Warnock

This Page Left intentionally Blank
posts - 36, comments - 7, trackbacks - 8

My Links

News




Archives

Post Categories

Developer Blogs

Development Community

Just Good Enough?

So, it has been a couple of weeks since I contributed to this.  It has been quite a busy few weeks.  Work, a two-week road trip (with my 3-year-old son, too) and several other matters have occupied my time.

 

Don’t forget that there is a Code Camp in Orlando on March 25th, 2006 at UCF.  I believe you can still register for this event at the Microsoft Events Site.  It is event code: 1032290514.   There are many excellent presenters and topics scheduled.

 

So, without further ado, my opine (for what it is worth)…

 

Last night I was fortunate enough to attend the Sarasota .NET Developers Group meeting (www.sarasotadev.net) during which Thomas Fuller (www.soapitstop.com) gave an excellent presentation on the Upgrade Path to WCF with ASMX 2 and WSE 3.  Afterwards, while enjoying my favorite beverage at the local pub, a small discussion transpired.  As a passionate advocate of good coding style and code quality, I am known to advocate that anything worth doing is worth doing well or at least to your best ability.  Yet, last night someone seemed surprised when I made the statement, “We should only engineer and create software to be only as good as considered necessary, expected or desired.”

 

As a Software Engineer, I do consider each developer as a craftsman who should hone their skills to the maximum.  And, I believe that each of us has a responsibility to write the highest quality code desired.  BUT we also have to recognize that for MOST of our projects, it is not expected or desired that we create an extremely high quality and performance-tuned system.  In fact, we are doing our patron quite a disservice if we attempt to do so. If we spend too much time creating a masterpiece mural, when we were commissioned to create a charcoal sketch, we have just decreased productivity and used additional resources that were not required.  Conversely, if we create a chair when we were requested to create an ornate deacons bench, we again have not lived up to our obligations.

 

We all expect that we can go to the local discount house and purchase a “mass-produced” and “good quality” item.  And, when we purchase it, we expect to get exactly what we asked for a particular price.  We also expect to be able to get fast food and yet are able to go to a fine restaurant and purchase a gourmet meal.  In fact, when I go to purchase an off-road vehicle, I do not want a Luxury SUV.  It has too many bells and whistles. It is too fancy.  And, while it is extremely nice, I can’t easily clean it out when I climb in wet and muddy.  Even though I would love to have one, if someone gave it to me, it would not serve my purpose or fulfill my desire for an off-road vehicle.

 

We each have a responsibility to engineer and create software that performs the requested functionality with the desired performance level and at the desired quality level within the appropriate schedule.  While we may suggest new features and express that we feel that the performance or quality expected is lacking, we are not at liberty to add extra functionality and features or expend additional effort and resources to ensure a greater level of quality or performance.  If the performance gain or improved quality does not cost additional effort and resources or if they are there by default, it is a good thing; however, we should be careful to not sacrifice future extensibility.

 

Many people believe this is blasphemous. But, while we should all be skilled craftsmen and artisans, we should also remember to do what we are expected to do and do it to the best of our ability.  Remember, Michelangelo knew when to create the Sistine chapel and when to create a quick portrait so that he could support his art.  The same can be said of Mozart; every piece could and should not be a symphony.

 

I do not want to discourage anyone from always performing to their maximum potential. If you can meet the project expectations and requirements and exceed quality expectations in less time and using less resources then by all means do so.  But, don’t waste the additional features, creativity and craftsmanship on a project manager, patron or client that neither desires nor appreciates it and certainly does not want to pay for it.

 

 

So save your creative masterpieces for those who desire it, recognize it, request it and above all appreciate it.

 

§ HAPPY ST. PATRICKS DAY! §

 

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati

Print | posted on Friday, March 17, 2006 10:47 AM |

Feedback

Gravatar

# re: Just Good Enough?

Amen! This is foundational thinking to delivering applications through automation. As the shift to software industrialization continues it will take pragmatic reasoning like this to keep the dream alive. I still think if you have obvious best practices that can lead to optimum performance, security, and other non-functional quality metrics then by all means do them. In fact find those best practices and start to figure out how to implement them seamlessly via tools or processes. If you inject these things without having to find them after a bunch of code is written then the barrier for entry is much lower. As AJ says, I would never make a recommendation for bad coding or bad practice adoption because of the need to produce "just good enough" application. However, there is always a balance to strike and that balance comes from the time and money a consumer is willing to spend.

I just loved this post (as you probably knew I would) and had to piggy back. Awesome stuff AJ!!!
3/27/2006 3:58 AM | Tom Fuller
Gravatar

# re: Just Good Enough?

Very interesting, both the article and comment. I work in a pro services shop where the SOP goes something like this. Code it anyway you can to get it to work. Show the client to show progress. After looking at it for a while, refactor (if time and money permit) what you coded to make it better ala Martin Fowler style and then document it.

Sometimes we only get to the “code it anyway you can to make it work stage” and the customer says good enough and doesn’t want any documentation or refactoring. So much for craftsmanship…

While I am a big supporter of software industrialization, I see our customers thinking that IT is a commodity and anyone can do it. Processes? How can we have good process when we still have hammers and chisels banging out code instead of CAD programs and milling machines? Some food for thought.

Keep up the good writings! Cheers, Mitch
4/21/2006 9:03 AM | Mitch Barnett
Comments have been closed on this topic.

Powered by: