“Clean Code” by Robert C Martin uses the phrase “code sense” when describing a developer’s relationship with clean code.  I like this phrase.  It represents the intuition that goes with looking at code.

He writes about how most people can identify messy code.  The problem comes in how to make it better.  This “code sense” lets people “see options” and “chose the best variation.”  This whole passage comes from a section subtitled “The Art of Clean Code?”.

I find it particularly interesting the comparison to art.  Especially because art is part talent and part learned.  The talent part comes from having the ideas and certain skills.  The learned part helps one know what tools are available.  A painter learns about the types of paint available.  A developer learns about refactorings.  These are all tools in the toolbox.  You still need a human to figure out when and where to use them.

—-

This week, we are hosting Uncle Bob (Robert C Martin) at JavaRanch in the Agile and Other Processes forum.  Come on in, ask him a question or join the discussion.  You might even win a free copy of the book Clean Code: A Handbook of Agile Software Craftsmanship.

When I wrote about defending the code, I described how we don’t want to meet a date at the expense of our ability to meet future dates.  This applies to future projects as well.  If we meet the production date for the first project my producing a shaky pile of code, what is going to happen to the next project using that code base.  Some things can be scheduled for refactoring between projects.  This approach also requires trust on both sides for it to actually get done.  It also only works with selected and specific types of refactorings.

I think this is similar to Robert C Martin’s discussion on the “total cost of owning a mess”.  (Also from “Clean Code”.)  I like this expression because I think it accurately reflects what happens.  Changes get harder and harder to make as does the code mess.  They also become more and more risky.  Messy code is more likely to  introduce bugs when touched.  And bugs make the total cost of ownership skyrocket.  Which leads to an unfortunate feedback loop where things spiral out of control.  So it’s our job as professionals to make sure we do not introduce a mess and encourage our teammates to do the same.

On the other hand, we often have a mess as the status quo.  It might have been inherited from the prior author of the code.  Or it might have just snuck up on us.  When this happens, we can still try to make things better.  Even if it’s a tiny bit at a time.  Or by not making things worse.  It’s so easy to say “well it’s already a mess, so I’ll just add this hack here.”  That’s how it got to be a mess in the first place!

—-

Starting in a few hours, we will be hosting Uncle Bob (Robert C Martin) at JavaRanch in the Agile and Other Processes forum.  Come on in, ask him a question or join the discussion.  You might even win a free copy of the book Clean Code: A Handbook of Agile Software Craftsmanship.

As I read “Clean Code” by Robert C Martin, I was particular drawn to the passage about why unrealistic commitments should not be an excuse for writing bad code.  He points out that while it is a manager’s job to “defend the schedule and requirements”, it is a developer’s “job to defend the code with equal passion.”

What management says vs what management wants

One way this becomes a problem is when a developer hears management say “I want it by Tuesday.”  They may want it by Tuesday, but does that mean they are getting it by Tuesday.  The manager also wants it to work correctly and meet all the requirements. A manager isn’t going to be happy if we claim it is done on Tuesday and then a whole pile of rework needs to be done afterwards.  This really means the task wasn’t done by Tuesday and we just claimed it was.

“Done”

The manager also doesn’t want this one date to be met at the cost of meeting other dates. One way this comes up is by saying the task is done while silently thinking that parts of it will be done “later.”  Regardless of whether “later” ever comes about, the task isn’t REALLY done.  When I disagree with someone on whether a task is done, I’ll ask if they need anymore time to work on things related to it.  This may bring up parts of the task that aren’t really done.  Sometimes it brings up additional tasks that were discovered during this task.  Either way, it is often a productive answer.

Trust

When unrealistic estimates come up, there are often two responses.  One is to silently accept it knowing the date will not be met (or will be met at the cost of other things) because it is “what the manager wants.”  The other is to discuss why the estimate will not be met with management.  Of course, the later requires much more energy at first.  However, it pays off in getting everyone to have a realistic understanding of the project.

Schedule gambling

These other desires tend to be implicit, so we only hear the deadline. That doesn’t mean that the manager wants it done by Tuesday at the expense of all else.  I’m fond of saying that management would rather meet the production date than a development date.  So if we are meeting the development date at the expense of something that affects the production date, management will really be less happy.  This may be sloppiness that makes other tasks take longer or leaving parts of the task incomplete.

What all of these things have in common is that it is our responsibility as developers to keep management up to date and provide them with accurate visibility into what is going on within the project.

—-

This coming week we will be hosting Uncle Bob (Robert C Martin) at JavaRanch in the Agile and Other Processes forum.  Come on in, ask him a question or join the discussion.  You might even win a free copy of the book Clean Code: A Handbook of Agile Software Craftsmanship.