What makes a pragmatic programmer

One of my all time favorite software books is "The Pragmatic Programmer, From Journeyman to Master". I was flipping through it looking for something or another and ran across the section titled "What Makes a Pragmatic Programmer?".

It seemed relevant since we are currently in the process of scaling out our Agile team, so I thought I'd pass it along.

Okay, so what makes a Pragmatic Programmer?

Early adopter/fast adapter. You have an instinct for technologies and techniques, and you love trying things out. When given something new, you can grasp it quickly and integrate it with the rest of your knowledge. Your confidence is born of experience.

Inquisitive. You tend to ask questions. That's neat—how did you do that? Did you have problems with that library? What's this BeOS I've heard about? How are symbolic links implemented? You are a pack rat for little facts, each of which may affect some decision years from now.

Critical thinker. You rarely take things as given without first getting the facts. When colleagues say "because that's the way it's done," or a vendor promises the solution to all your problems, you smell a challenge.

Realistic. You try to understand the underlying nature of each problem you face. This realism gives you a good feel for how difficult things are, and how long things will take. Understanding for yourself that a process should be difficult or will take a while to complete gives you the stamina to keep at it.

Jack of all trades. You try hard to be familiar with a broad range of technologies and environments, and you work to keep abreast of new developments. Although your current job may require you to be a specialist, you will always be able to move on to new areas and new challenges.

We've left the most basic characteristics until last. All Pragmatic Programmers share them. They're basic enough to state as tips:

Tip 1
Care About Your Craft
We feel that there is no point in developing software unless you care about doing it well.

Tip 2
Think! About Your Work
In order to be a Pragmatic Programmer, we're challenging you to think about what you're doing while you're doing it. This isn't a one-time audit of current practices—it's an ongoing critical appraisal of every decision you make, every day, and on every development. Never run on auto-pilot. Constantly be thinking, critiquing your work in real time. The old IBM corporate motto, THINK!, is the Pragmatic Programmer's mantra.

If this sounds like hard work to you, then you're exhibiting the realistic characteristic. This is going to take up some of your valuable time—time that is probably already under tremendous pressure. The reward is a more active involvement with a job you love, a feeling of mastery over an increasing range of subjects, and pleasure in a feeling of continuous improvement. Over the long term, your time investment will be repaid as you and your team become more efficient, write code that's easier to maintain, and spend less time in meetings.

Warren Buffett on Hiring

In looking for someone to hire, you look for three qualities: integrity, intelligence, and energy. But the most important is integrity, because if they don’t have that, the other two qualities, intelligence and energy, are going to kill you.

Found at the Laws of Simplicity blog, quoting from the book "The Tao Of Warren Buffett".

JavaScript Double Bang

Lately I've noticed the use of the JavaScript double bang (!!) cropping up in our code. For example, I ran across this the other day:

var hasEmployeeBeenAdded = !!this.getEmployee(employeeID);

Now I'll have to admit that is a cool little trick. However, it got me to thinking...is this the best way to express this statement? While the value above is assigned to meaningful variable name, I'm debating with myself whether that is enough.

At first glance the double bang is non-sensical, since !!true is true and !!false is false. But taking a JavaScript "not" and inverting it with another "not" gives the handy side effect of doing a cast, or conversion, into a primitive boolean value.

Okay, so as is often the case with JavaScript, there are many ways to achieve the same result. Here are some examples, all returning false, that convert an undefined variable into a boolean primitive.

We have the previously mentioned double bang:

var myThing;
return !!myThing;

Then there is the ternary operation:

var myThing;
return myThing ? true : false;

Pretty clear what's going on there. So what about a plain old equality check:

var myThing;
return myThing !== undefined;

That seems to more clearly state what is going on, but it's just not as short as the double bang, and who wants to write an undefined check everywhere. Plus, it breaks if the variable is null or some other empty value.

So lets go back to the intent of the original code snippet.. a cast into a boolean. That brings me to this, using the JavaScript Boolean object to perform the conversion:

var myThing;
return Boolean(myThing);

That seems to state exactly what it is trying to do: casting the value of myThing into a boolean.

In his book "JavaScript: The Definitive Guide", a must have for any JavaScript developer, David Flanagan explains the effect of calling the Boolean object as a function (without the new keyword).

The values 0, NaN, null, the empty string "", and the undefined value are all converted to false. All other primitive values, except false (but including the string "false"), and all objects and arrays are converted to true.

In closing, I think the double bang might be a good interview question to try and trip somebody up, but I'm in favor of using the Boolean constructor for the sake of clarity.

SOLID, from the top

SOLID. The acronym (of acronyms) coined by Robert "Uncle Bob" Martin. Yeah, I know, just what we needed... acronyms made up of more acronyms. So is there actually a method to this madness? Well, lets see.

The first glimmer of the SOLID principles can be found when, in 1995, Uncle Bob laid out his ten commandments of Object Oriented Programming. That list was eventually streamlined and broken out into 5 distinct Principles. He and others have written and spoken about them many times since.

First things first.  Here you will find no listing of the 5 principles that make up SOLID. By jumping straight to the principles, I feel that its easy to miss out on the full benefit of learning about SOLID.  Besides, if you don't buy into the principles as a whole, it's likely not worth your time to learn the individual principles.

Therefore, when starting with SOLID, I think it's best to first step back and take a look at the big picture.

Okay, so what are these SOLID principles all about? The best high level description I've seen comes from the man himself, in a blog post titled "Getting a SOLID Start."

The SOLID principles are not rules. They are not laws. They are not perfect truths. The are statements on the order of “An apple a day keeps the doctor away.” This is a good principle, it is good advice, but it’s not a pure truth, nor is it a rule.

That's a good start, but I think the missing piece here is... what is the source of these principles? Did Uncle Bob drink too much whiskey and just make them up to sound smart?

Actually, in his PPP book, Uncle Bob explains that the idea behind the principles is to share the wisdom he has gained in his twenty plus years of software development.  I have to think that he, along with others in the fifty plus years of OO programming, probably learned a lot of lessons the hard way.  Hopefully, by keeping SOLID in mind when developing, we can benefit from some of the pain our predecessors when through.  Uncle Bob continues with...

The principles are mental cubby-holes. They give a name to a concept so that you can talk and reason about that concept. They provide a place to hang the feelings we have about good and bad code. They attempt to categorize those feelings into concrete advice. In that sense, the principles are a kind of anodyne [-capable of soothing or eliminating pain]. Given some code or design that you feel bad about, you may be able to find a principle that explains that bad feeling and advises you about how to feel better.

The paragraph above hits on one of the major benefits of SOLID. It gives us some common names, and acronynms, to make it easier to discuss OO design.

The paragraph also ties SOLID to code smells. The PPP book repeatedly points out that often the best way to use SOLID is to wait until there is a code smell, and then apply one or more of the principles to reduce or eliminate the smell.

Uncle Bob wraps up the description of the principles with...

These principles are heuristics. They are common-sense solutions to common problems. They are common-sense disciplines that can help you stay out of trouble. But like any heuristic, they are empirical in nature. They have been observed to work in many cases; but there is no proof that they always work, nor any proof that they should always be followed.

In PPP, he points out that trying to apply the principles before they are needed actually creates the code smell of needless complexity. He states that the incorrect usage of the principles can be worse than not applying them at all.  He takes this a step further when relating SOLID to learning how to paint.

This is an important point. Principles will not turn a bad programmer into a good programmer. Principles have to be applied with judgement. If they are applied by rote it is just as bad as if they are not applied at all.

Having said that, if you want to paint well, I suggest you learn the rules on the paint can. You may not agree with them all. You may not always apply the ones you do agree with. But you’d better know them. Knowledge of the principles and patterns gives you the justification to decide when and where to apply them. If you don’t know them, your decisions are much more arbitrary.

So, in the end, looks the the SOLID principles won't replace good judgement or experience. Damn, guess there really is no silver bullet. However, I think the SOLID principles are good tools for improving the quality of Object Oriented code.

Here are a few of the better sources on SOLID:

• Uncle Bob's page on SOLID
• Pablos topic of the month: solid principles (lost techies)
• Pablos ebook (combines all solid posts)

Quote: Speculation

“If you believe that the future is uncertain, and you believe that you can cheaply change your mind, then putting in functionality on speculation is crazy. Put in what you need when you need it.” 

--KentBeck, in Extreme Programming Explained, Simple Design, p. 57.

When to Diagram and When to Stop

When coming to the UML section of Uncle Bob's PPP book, a sense of dread overcame me.  I've read several books on UML in the past it always seemed to be overkill for what I wanted to do.  I have to admit I expected Bob to use the UML section to preach to us about how we should all be writing UML documents before we code.  This was far from the case.  Actually, I think he gives some very good advice about how to use diagrams in general, especially in an agile environment.

The recurring theme throughout the chapter was that you typically do not want to hang on to diagrams.  In most cases, they should be drawn on a whiteboard and then discarded once the ideas behind the diagram have been communicated.

Get into the habit of throwing UML diagrams away.  Better yet, get into the habit of not creating them on a persistent medium.  Write them on a whiteboard or on scraps of paper. Erase the whiteboard frequently, and throw the scraps of paper away.  Don't use a CASE tool or a drawing program as a rule.  There is a time and place for such tools, but most of your UML should be short-lived.

One of Uncle Bob's points that I really liked was that you should never let the diagram get to far away from code.  The purpose of diagrams are to help in writing code.  When a group of developers stand around a whiteboard looking at a diagram, they should all know how the diagram translates to code, otherwise you are building castles in the air.

I also liked the following lists Uncle Bob created for when to diagram and when to stop.

Draw diagrams when:

• Several people need to understand the structure of a particular part of the design because they are all going to be working on it simultaneously.  Stop when everyone agrees that they understand.
• You want team consensus, but two or more people disagree on how a particular element should be designed.  Put the discussion into a time box, then choose a means for deciding, such as a vote or an impartial judge.  Stop at the end of the time box or when the decision can be made.  Then erase the diagram.
• You want to play with a design idea, and the diagrams can help you think it through.  Stop when you can finish your thinking in code.  Discard the diagrams.
• You need to explain the structure of some part of the code to someone else or to yourself.  Stop when the explanation would be better done by looking at code.
• It's close to the end of the project, and your customer has requested them as part of a documentation stream for others.

Do not draw diagrams:

• Because the process tells you to.
• Because you feel guilty not drawing them or because you think that's what good designers do.  Good designers write code.  They draw diagrams only when necessary.
• To create comprehensive documentation of the design phase prior to coding.  Such documents are almost never worth anything and consume immense amounts of time.
• For other people to code.  True software architects participate in the coding of their designs

End of an Era

For the past two years or so, it seems I rarely read an entire article in MSDN magazine.  The exception to the rule has been the Patterns in Practice series of articles by Jeremy Miller, aka the Shade Tree Developer. January marked the end of the series.  While I don't blame Jeremy for wanting to move on to other things, I am sad to see this era come to an end.  I've recently gone back and re-read the 10 articles in the series and listed them here going from most favorite to least. I also added the topics covered in each article.  As the saying goes, they are chocked full of goodness.

The Open Closed Principle

Cream of the crop, if you ask me.  Contains Single Responsibility Principle, Chain of Responsibility Pattern, Double Dispatch, Liskov Substitution Principle, and more.

Cohesion and Coupling

Code Smells (Divergent Changes, Feature Envy, Shotgun Surgery), Inappropriate Intimacy, Law of Demeter, Tell - Don't ask, Say It Once and Only Once.

Incremental Delivery Through Continuous Design

Predictive versus Reactive Design, Importance of Feedback, Last Responsible Moment, Reversibility, YAGNI and the Simples Thing that Could Possibly Work, 

Persistence Patterns 

Domain Models, ORM, Active Record, Lean Programming, Data Mapper,  Repository Pattern, Identity Map, IOC tools, NHibernate, FluentNHibernate, Virtual Proxy Pattern, 

Design For Testability

What is Testability?, Mocking Best Practices, SpecUnit, Respository Pattern, Gateway Pattern, Small Tests before Big Tests.

The Unit Of Work Pattern and Persistence Ignorance

The title pretty much says it all.

Functional Programming for Everyday .NET Developers

First-Class Functions, Lambdas as Data, Passing Blocks, Delayed Execution, Memoization, Map/Reduce Pattern, Continuations,.

Internal Domain Specific Languages

Literal Extensions, Semantic Model, Fluent Interfaces and Expression Builders, Object Initializers, Nested Closure, IronRuby and Boo.

Convention over Configuration

Essence vs. Ceremony, Say It Once and Only Once, Sensible Defaults. 

Object Role Stereotypes

Responsibility-Driven Design, Service Provider, Coordinator.