Carpentry and Magic Resizing Logs

He was a pretty good carpenter, too, and knew a lot about his trade. He made a decent living selling his wares in the local market.

As the carpenter wandered through the forest looking for good trees to use for his next project, he stubbed his toe on a small lamp. He picked up the lamp and examined it closely. While trying to ascertain the origins of the lamp, he was surprised to see it begin to glow and shimmer. Presently, a genie burst forth.

The two contemplated each other in silence for a moment. At long last, the genie spoke.

"I see that you are a skilled worker of wood. I will reward you by granting a single wish."

The carpenter pondered for a moment, and then brightened up - he knew exactly what to wish for.

"You know the old rule, measure twice, cut once? I wish that I could break that rule. I want to be able to cut as many times as I need to until I get things perfect - even if it means making the wood longer instead of shorter!"

A mischievious glint appeared in the genie's eyes as he intoned, "Your wish is granted."

With that, the lamp shattered into a thousand pieces, the genie disappeared, and the carpenter went about his business. Within a few hours he was so consumed with his work that he completely forgot about the encounter with the genie, and his wish.

Days later, as he was feverishly working on a difficult bit of cabinetry for a local aristocrat, he mistakenly chopped an extra inch off of a plank. Overwhelmed by despair, he sat down, holding the ruined wood in his hands, and fought back tears - it was the last piece of wood that matched the cabinets, and without that piece intact, he would have to start over in order to ensure everything was of the demanded quality.

As he sat in frustrated silence, he suddenly recalled the genie, and his wish. With a deft snap of his fingers and a gentle tap on the plank, the carpenter magically restored the wood to its unmarred state.

Overjoyed, he returned to work, and soon had delivered the best cabinetry ever seen by the townsfolk.

Over the next few years, the carpenter grew ever more reliant on his ability to un-cut his work. Soon enough, he stopped measuring things altogether, and simply slapped together random chunks of wood at a whim. If they didn't suit his fancy, he'd pick a few bits to chop off and try again.

Meanwhile, word of his productivity and skill had spread far and wide. Eventually, a visitor arrived from a distant kingdom, and asked to see the famous carpenter and his majestic constructs.

The visitor walked into the woodshop and started to look around. Everywhere he saw chaos: haphazard blobs of shapeless mess that only barely resembled chairs, or tables, or whatever else. Stunned, he asked his guide quietly if he was in the right place - surely the world-renowned carpenter made better things than this!?

Despite his attempts at tact, however, the visitor was overheard by the busy carpenter, who emerged from a pile of sawdust and shavings to confront his guest.

"Of course I'm the world-famous carpenter! Don't mind all this stuff, this is just work in progress. After all, many of my customers don't even know what they want until after I make it for them! So I just make a version, and they tell me what to change, and we repeat this every two weeks until we're both happy. It's a great process."

The visitor walked away and returned to his homeland, saddened that he had gone so far to see a master craftsman, and instead had discovered someone not even worthy of an apprenticeship in his native kingdom.

Of course, none of this has anything to do with woodworking, genies, or distant kingdoms.

Automated refactoring tools have made us lazy and unthinking, and agile methodologies have worked hand in hand with such tools to encourage us to develop software this way. Don't try to use your brain! Don't think ahead! Never talk to your customer beforehand to come to an agreement! Just blindly surge forwards, cobbling together whatever dreck it takes to make it through the sprint, and then "fix it" later!

Genies may sound nice, but of course they are always devious and our "granted" wishes always turn out a little less awesome than we imagined. The carpenter got his automated refactoring tools, yes, but he also lost the respect of his fellow craftsmen - who may well have been amazed by his abilities if he had used them judiciously.

So just remember: if refactoring tools are saving you a nontrivial amount of time and mental effort on a daily basis, the genie is having the last laugh.

Except that in your story, doing things in a lazy way with the aid of magic tools still resulted in him creating better products, faster, than doing it the careful way. Which is rather the point isn't it - the end product?

Except that in your story, doing things in a lazy way with the aid of magic tools still resulted in him creating better products, faster, than doing it the careful way. Which is rather the point isn't it - the end product?

I think that is a valid point of view, but I think it is a little too narrow. For example, I assume we have all worked with that engineer who has lots of work in progress but nothing you can use until the milestone/deadline and then you have to use what ever was produced. The result may well be a product that works... or appears to work, but is a turgid monstrosity. If it is a product that needs to be maintained or that other engineers have to work on, I think that the simply looking at the end product is insufficient. Or, rather, evaluating the end product is not a trivial task and depends upon the user group. This is the lesson that I take from the end of the story.

Except that in your story, doing things in a lazy way with the aid of magic tools still resulted in him creating better products, faster, than doing it the careful way. Which is rather the point isn't it - the end product?

I think this is a biased interpretation based on your own preconceptions ;-)

The point of the story is that he did none of those things. The products were worse, took longer, and looked terrible to other field experts. This is consistent with the way software seems to be produced under most "agile" teams I've encountered.