I will be re-reading the following quotes from Sandi Metz’s Practical Object-Oriented Design every morning before I start coding:

Object-oriented design is about managing dependencies. It is a set of coding techniques that arrange dependencies such that objects can tolerate change. In the absence of design, unmanaged dependencies wreak havoc because objects know too much about one another. Changing one object forces change upon its collaborators, which in turn forces change upon its collaborators, ad infinitum. A seemingly insignificant enhancement can cause damage that radiates outward in overlapping concentric circles, ultimately leaving no code untouched.

This makes sense of why dependency injection containers exist, the principle of inversion of control, and how to split up classes into the right responsibilities.

Asserting that code should be easy to change is akin to stating that children should be polite; the statement is impossible to disagree with, yet it in no way helps a parent raise an agreeable child. The idea of easy is too broad; you need concrete definitions of easiness and specific criteria by which to judge code. If you define easy to change as

• changes have no unexpected side effects,
• small changes in requirements require correspondingly small changes in code,
• existing code is easy to reuse, and
• the easiest way to make a change is to add code that in itself is easy to change,

then the code you write should have the following qualities. Code should be

• Transparent The consequences of change should be obvious in the code that is changing and in distant code that relies upon it.
• Reasonable The cost of any change should be proportional to the benefits the change achieves.
• Usable Existing code should be usable in new and unexpected contexts.
• Exemplary The code itself should encourage those who change it to perpetuate these qualities.

Code that is Transparent, Reasonable, Usable, and Exemplary (TRUE) not only meets today’s needs but can also be changed to meet the needs of the future. The first step in creating code that is TRUE is to ensure that each class has a single, well-defined responsibility.

Optimising for unknown future requirements seems like a great way to go about writing code that’s usable today as well.

Filed under:coding

A letter from an unknown Luddite to a local magistrate:

Huddersfield 21 October 1812 Ratclif

Sir,

I drop you this as a warning that I have for some time Eyed you as your Publick character act with so much injustice to almost every individual that has had the misfortune to come before you that I and my two Assocites is this hour your sworn Enimes and all his Magistes forces will not save you, for I dow not regard my own life if I can have reveang of you which I mos ashuredly will make myself another Jhn Bellingham and I have the Pellit mad that shall be wet in you Harts Life Blood if I should dow it in the hous of God

I with hatered your sworn Enemie Anonimous

Add. Joseph Ratclif Es^qr Millns Bridge

There’s something powerful about even the meanest and most brutish of the Luddite’s threatening letters. Both assertive and cowardly, at-once vengeful and impotent, the enemie anonimous rebukes the powerful and spits the venom of the downtrodden.

Text from Writings of the Luddites by Kevin Binfield.

Filed under:luddites