Clean code is an important quality, but not the MOST important

-

Clean code is a book by Uncle Bob Martin that speaks to principles in software development that lead to high quality, legible software. This is a great book and every developer should read it once (or twice). The book outlines important tools and techniques, but these are not the end, they are a means. I've noticed a lot of folks treat clean code as the "secret sauce" that makes great software. Unfortunately, they take it a little too far and by being too focused on their secret sauce, they forget that it's worthless if the customer starves to death waiting for the secret sauce to be "perfect".

At one point early in the book, Uncle Bob uses the metaphor of physicians and hand washing. In particular, he makes a point that it would be unrofessional and possibly illegal for physician to not wash his hands before surgery, even if the patient (the customer) asked for it. I like this metaphor and I think he makes a good point, but I feel he narrows the perspective too much. I respect his position, and it makes complete sense when talking about elective surgery, but doesn't apply in all situations. In my experience, most software development isn't like elective surgery with a controlled environment and a sterile operating room, but more like treating wounds in a combat zone under direct fire. In this sort of an environment, hand washing (clean code) is important, but not always as important as stopping the bleeding and/or saving the patient's life. It's often more important to get the patient out of harms way and stop the bleeding than it is to make sure you don't introduce the risk of infection at some future point. Sometimes, you might need to even sacrifice not only hand washing, but even a leg or two in order to save the patient's life and you've done the right thing.

The more important factor beyond keeping things clean is understanding and delivering value to the customer in a manner (i.e. cleanliness) that is appropriate for the environment. I've been on a few projects where there is 100% test coverage, the code is a beautiful work of art, but the business customer ultimately cancels the project because they cannot afford to operate without the business value the code was supposed to deliver. In our combat zone metaphor, some practitioners are so busy washing their hands, they've forgotten that the goal is to save lives, not prevent infection. Clean code is an important goal, just like preventing infection is an important goal, but not THE most important goal.

Developers, clean code is important, it is downright essential in the long run, but it is not the primary goal of software development. Learn the principles and techniques to keep your code clean, but don't forget that your customer needs the software to do something for them and no matter how clean your code might be, if it doesn't provide real business value in a timely manner, the customer isn't getting what they need. In other words, don't let your patients die from blood loss while you're busy washing your hands.

Comments

Hannibal said…
Nice article but there is no such thing as 100% code coverage ;)
May 11, 2012 at 3:08 AM
Mike Mainguy said…
I would tend to agree, once there is one line of untested code in the operating system (or a device driver) I guess technically you've lost coverage.
May 18, 2012 at 8:05 AM
Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules ...
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u...
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa...
Read more