Lines are starting to get drawn for the Great Quality Wars of '09.  On one side you have camp led by Joel Spolsky and the now infamous Stack Overflow Podcast #38, and the other camp led by Uncle Bob.  I'm sitting this one out, from what I can see so far, both sides are going to get bloodied up where the discussion turns from a reasonable and positive debate to personal attacks.  We have a lot of problems in our industry and dividing it into factions won't help anyone.  Especially when I see this religious war based on how do I get there, not where do we want to go.

This, being on a much greater scale, reminds me of the Great Coding Convention Battles I participated in within a company in the early 90's.  One of the stupidest things we discussed over the course of a month of meetings was whether to use the following syntax for one line after an if statement.

if(true)
   DoSomething();

or

if(true)
{
   DoSomething();
}

Looking back this was a tremendous waste of time, albeit a relatively fun discussion in our meetings where both sides decided the other side was a bunch of hacks. 

I was in the

if(true)
   DoSomething()

camp unless I wasn't. 

For the case of:

if(true)
    while(someCondition)
        DoSomethingElse();

I would use the convention:

if(true)
{
    while(someCondition)
         DoSomethingElse();
}

where I would be in both camps.  What does this mean?  Does this mean I'm a moderate?  Well no, I do have very strong views on both coding (and politics but I'll spare you the pain on discussing my political views here).  I think the main reason I had strong feelings on my approach was that the other camp wasn't using C/C++ in their day to day work and kept bringing up examples and what *experts* said about the topic and under no circumstance should we have a block of code not enclosed in curly brackets.  My camp lived in a C/C++ editor for most of our work.

Do I agree with the statement that Quality doesn't matter?  No.  Do I agree with the statement that Quality is the most important thing?  No.  For any system there is really only one true measurement of success:

In the long term is your user community satisfied and will they continue to use your software to enhance their business or personal lives. 

Anything else is pure rubbish.  You may have a very high quality system that is just a joy to maintain, but unless people use your software, you probably won't (and shouldn't) get past V1.0.  You also could have a system that you deploy within a month or two that people just love, but it has tons of bugs in the core architecture and can't be maintained, you probably won't get beyond V1.0 either.

Quality is an important attribute of your system, however quality is not free.  Building a quality systems is not ensured by a set of tools, techniques or processes.  Quality is a result of an individual's commitment and a culture within your organization.  

There is a danger on both ends of the spectrum.  On one end of the spectrum there is "we don't need these new fangled tools and techniques, our Cobol and Assembly Language application runs just fine", yeah right, there's a real competitive edge.  I'm probably not going to buy or use your software, and if I do, I'm probably not going to apply any updates unless absolutely necessary.  On the other end of the spectrum, we try to rigorously follow the latest fads something like not writing a single line of code without a test, attempting to achieve 100% code coverage, or program exclusively against interfaces.  While this does sound good in reality are you putting too much trust in your metrics?  Code coverage of 100% (or even 90%) means your code was run, that's it.   I may be different, but I know most of my bugs are edge conditions I don't account for even if I do have a test suite covering that chunk of code.  The code coverage metric does little to protect me against these problems. 

What is the middle ground here?  It's actually pretty simple, think for yourself, make sure you write lots code that makes it into production, it doesn't do much good to get your code to a certain point and gloss over all the little details.  Also read as much as possible. 

Although I think the SOLID Principles offer a number of good concepts,  I personally don't agree with all those concepts.  You may agree with all those concepts.  That's OK.  One area I disagree with is the Single Responsibility Principle or SRP.  I've seen implementations of this in code a code base I needed to extend, and it's just not my cup-of-tea, too much noise, classes are not free.  The developer swore by this technique.  That's OK. 

I wish I could find the transcript, but let me paraphrase a discussion of SRP from Uncle Bob's Hanselminutes interview (right around 3 inutes into the podcast)

Uncle Bob: This is somewhat out of the norm for object oriented design.  Early Object Oriented Design Principals had us grouping together functions of that operated on the same data structures so that the methods of the class manipulate the same variables. 

Scott: That definitely flips things on its head.

Early on I learned one of the core principals of Object Oriented Analysis and Design is it's all about the data and methods acting upon that data via encapsulation.  Over time your business rules will probably change, however the structure of your data will remain fairly static.  The way I design LOB type apps is ruthlessly focus on my physical data model.  If you don't get that right, you will be fighting with an impedance mismatch all through your development cycle.  Although I could certainly see the value of a different approach, I keep my business objects 1:1 in sync with the database tables.  The primary reason for this is simplicity, once you break that relationship you introduce a mapping layer that is sometime necessary but comes at a cost of additional code.  The only code you know has zero bugs is code you don't write.

Maybe I'm "old-school" but my process has allowed me to pay the bills for the past 20 years now.  In some cases the developers picking up my code said, this is so incredibly easy to maintain and the hand off went smoothly with very few support calls.  In other cases, people just said it was a mess.  It seemed like people that liked my code have been in the industry 10+ years and have handed over legacy code themselves.  The people that thought I was a hack usually had less than 5 years and already knew everything there was about writing software.  They were just waiting for their first chance to start from scratch, build a product and show us old-timers how it's done.  I suspect, at one time I thought I knew everything about writing code.  Maybe this is a right-of-passage?

Using classes to group together functions just doesn't smell right to me, it may to you. That is ok.  I have the right to express my opinion just as Joel and Uncle Bob did, neither of these two people are hacks and I don't think I am either.  We as an industry need to do a better job of leaving out the religion and personal attacks, software is hard.  Period.  What works for one person on one project would cause a different person to fail.  

Another thing to think about in adopting and evaluating new techniques and technologies is one of the concepts of the Software Capability Maturity Model or CMM.  If you are a Level 1 organization, you cannot skip directly to a Level 3 or 4 organization.  You must go through Level 2.  If you attempt to implement processes found at Level 3 or 4 you will fail. 

At any point in your career your toolbox contains a finite number of tools, over time you should be continually adding tools to your tool box or you won't advance in your career.  If you attempt to implement something like the SOLID principals before having in place effective requirements gathering, defect tracking, or a continuous integration process your time would be much better spent focusing on blocking and tackling exercises rather than more advanced techniques.  It's surprising how many organizations I've worked with that try to adopt the latest advanced technique, but their bug tracking is emails, source control is sorely lacking and requirements gathering consists of meetings where the main goal is for people to hear themselves talk and sound important! I've seen many more projects fail because of the lack of effective leadership, poor requirements or project management than I have because the programmers used the wrong technique or pattern.  Before we put stealth on our airplane, let's make sure our airplanes fly.

Over time there have a been considerable advances in our field of software engineering, some stick around some don't.  Are we still using those old Rational Rose Puffy Clouds.  I liked my Puffy Clouds!  I want my Puffy Clouds back!  None of these should be considered 100% bad and ignored, learn something from these, but don't just jump in and blindly implement without thinking.  Put what works for you in your tool box, have a full tool box and select the exact right tool to solve your problem and more importantly, know why you picked that tool.

I'm looking forward to the "smack-down" between Joel and Uncle Bob in an upcoming Stack Overflow episode!  Would be very interesting to see them on UFC as well.  In the mean time, I'm going to keep writing software, reading blogs and keep adding more tools to my tool box.