The Stone Cutters' Bounty

In antiquity, there was a nascent village nestled between a crescent-shaped mountain range and the sea. They worked hard and had plenty of food, so they considered themselves lucky.

Nobody told them how to be a village. It was the sort of thing that was springing up all over the world, at the time. We can scarcely explain, now, why it happened so suddenly, then.

The village started late and evolved slowly. They were amazed when they saw a small, wind-powered vessel approaching the shoreline.

Another Trick for Suffering Fools

Previously, I wrote about a trick you can use to deal a little more effectively with someone you consider to be foolish.

I have another one for you: Consider what else could be the problem.

How Much Time Do You Spend Refactoring?

Software development is really mostly about design, so we should spend most of our time refactoring.

Personally, I spend almost all of my time refactoring. If a feature doesn't "fit" in my current design, it's going to be hard to test, so the test-effort tells me it won't fit.

Redundancy vs. Duplication Examination - Method Calls

Previously, I wrote about redundancy and how it differs from duplication.

I'd like to dig into that situation a little with an example. Imagine a design where one class provides a method used by many others.

A basic static structure diagram

Redundancy - Replication of Purpose that You Might Have to Find

I’m sure there are plenty of definitions of redundancy. A naïve definition might just try to make it a synonym for duplication.

Duplication isn’t really a problem, though. Certain acts of duplication are the cause of certain redundancies – for instance, copy-pasting a method – so it’s natural for us to blame duplication for our problems.

Yet, even though it is sometimes the cause of a problem, duplication is not, in and of itself, a problem.

The problem exists when you need to make the same change to two or more things. Specifically, it’s a problem when you need to find two or more places to make the same change. The reason why it’s a problem is that you run the risk of missing one of the places where you need to make a change and you almost certainly will expend a lot of energy trying to mitigate that risk.

More on this to come.

Focus Versus Urgency

Many modern software development frameworks emphasize getting to done.

When transitioning to such a process from a traditional project-management structure, a lot of people seem to map this to the old concept of urgency. In other words, they think that "get to done" means "rush".

Software Development Thinking Applied to the Real World, Part VIII

(last week)