It’s contextual

“There is nothing either good or bad, but thinking makes it so”

A timeless comment on the human condition by Shakespeare’s Hamlet. It came to my mind as I was attending GOTO Online Bookclub featuring Kevlin Hanney.

The topic of the day was Udi Dahan’s Beware the share essay from the 97 things every programmer should know book. In it, Udi shares a story of his first job. Coming fresh from college, eager to prove himself, he looked for every opportunity to improve the codebase by pulling out shared code into libraries, only to find out during code review, that other developers were not too happy about it. On the contrary — reuse was frowned upon!

Kevlin opened the session by pointing out how Udi’s essay stands in contrast to another essay from the same book — Don’t repeat yourself by Steve Smith, which is all about the dangers of duplicate code (logic).
So who is right, Udi or Steve? They both are.

The duality of life

This kind of duality is not unique to software development. We come across it often in life, but it can still confuse or even scare people. We tend to seek easy, one-size-fits-all, solutions and if both Udi and Steve are right then how do we choose whose advice to follow?

Later in his essay, Udi states he came to realize he missed the critical part when blindly applying his eliminate code duplication rule — context. It is the context that matters and creating those shared libraries also came at a cost (increasing the dependencies between code that is using those libraries).

Kevlin continued on this, generalizing it to all software design patterns, principles, guidelines… Their usability and benefits are dependent on the particular context you are applying them in. And “context is a function of time”, so you need to be ready to re-asses your decisions as time goes by. Decisions that were perfectly reasonable at the time you made them, can become wrong with the passage of time (change of context).

What to do?

Hamlet is right but accepting this fact doesn’t mean we should be paralyzed by our lack of total understanding. We should act to the best of abilities given the current context (knowledge). But we should also understand how highly contextual all our decisions are and be ready to re-asses them as the context changes. Design patterns, “rules” and guidelines are there to help us but we should not lose sight of the context in which they are to be applied.