Beware the Share

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
-
It was my first project at the company. I'd just finished my degree and was anxious to prove myself - staying late every day going through the existing code. As I worked through my first feature, I took extra care to put in place everything I had learned - commenting, logging, pulling out shared libraries where possible, the works. The code review that I had felt ''so'' ready for came as a rude awakening - reuse was frowned upon!
+
It was my first project at the company. I'd just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature I took extra care to put in place everything I had learned &mdsah; commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt ''so'' ready for came as a rude awakening — reuse was frowned upon!
-
How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me - was it all wrong?
+
How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me. Was it all wrong?
It turns out that I was missing something critical.
It turns out that I was missing something critical.
Line 7: Line 7:
Context.
Context.
-
The fact that two wildly different parts of the system performed some logic the same way meant less than I thought. Up until I had pulled out those shared libraries, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of its changing business environment. Those 4 lines of similar code were accidental - a temporal anomaly. That is, until I came along.
+
The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought. Up until I had pulled out those libraries of shared code, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of the system's changing business environment. Those 4 lines of similar code were accidental — a temporal anomaly, a coincidence. That is, until I came along.
-
The shared libraries I created tied the shoe-laces of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the shared library required an order of magnitude more testing.
+
The libraries of shared code I created tied the shoelaces of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the common library required an order of magnitude more testing.
-
While I'd decreased the absolute lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical - had they been localized, it may have been justified, had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine.
+
While I'd decreased the absolute number of lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical — had they been localized, it may have been justified and had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine.
-
These mistakes are insidious in that, at their core, they sound like a good idea. And when applied in the right context, they are valuable. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared.
+
These mistakes are insidious in that, at their core, they sound like a good idea. When applied in the right context they are valuable. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared.
Beware the share. Check your context. Only then, proceed.
Beware the share. Check your context. Only then, proceed.

Revision as of 07:39, 17 February 2009

It was my first project at the company. I'd just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature I took extra care to put in place everything I had learned &mdsah; commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt so ready for came as a rude awakening — reuse was frowned upon!

How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me. Was it all wrong?

It turns out that I was missing something critical.

Context.

The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought. Up until I had pulled out those libraries of shared code, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of the system's changing business environment. Those 4 lines of similar code were accidental — a temporal anomaly, a coincidence. That is, until I came along.

The libraries of shared code I created tied the shoelaces of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the common library required an order of magnitude more testing.

While I'd decreased the absolute number of lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical — had they been localized, it may have been justified and had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine.

These mistakes are insidious in that, at their core, they sound like a good idea. When applied in the right context they are valuable. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared.

Beware the share. Check your context. Only then, proceed.

By Udi Dahan


This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools