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 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? Throughout 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.
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 four 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 the other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in ...
Get 97 Things Every Programmer Should Know now with O’Reilly online learning.
O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.