"Learn the principle, abide by the principle, and dissolve the principle."
- Bruce Lee
I first saw this line in one of Ron Jeffries's sig lines years ago. It struck me then and has stuck with me over the years.
I was reminded of it a few months ago when I read this observation about Scrum:
The intention of Scrum is to make [an organization's inadequacy or dysfunction] transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them.
The latest experience that reminded me of this was Udi Dahan's week long eye-opening Advanced Distributed System Design class. It's been like Yoda's teaching Luke Skywalker, "You must unlearn what you have learned."
Bruce Lee's thought has particular applications for software developers. I'll explain my interpretation of what he was saying and then apply it to software development.
Learn the principle
Step one is pretty simple: learn the subject you are exploring. If you want to do x, where x could be agile, scrum, TDD, DDD, CQRS, etc., there are tons of material available. When you feel like you've found a trustworthy source for the x that you currently want to do it'll provide instructions: break work into user stories, write a test for something before you build it, make sure a class has only one reason to change, etc. You'll need to discover for your x what are the things to do.
Warnings:
- If you learn to do a Judo Ashi Guruma throw, that's great and may even be useful in some situations, but if you start telling people that you "do Judo" just because of that, the people who really do do Judo are going to be annoyed with you and Ashi Guruma you to the floor. Keep this in mind when you casually leaf through the Blue Book and learn about entities, value objects, and repositories. Those chapters are an exciting read and the tools are useful. But be careful claiming to be "doing DDD." The first letter of DDD is for domain, not design; there may be a few more important things about DDD that you haven't picked up yet, and the people who have picked those up may get annoyed if you claim you're doing DDD just because you have an entity and an IRepository<T>.
- No matter how much you try to jump into Tae Kwon Do by learning the Reverse Spinning Hook Kick, you may not get it. That's because it's hard, and it builds on a foundation of other things that must come first. "But I don't have time for that; I just want a nifty move so I can start trashing bozos." Our tendency is to blame Tae Kwon Do. "I tried it; it didn't work for me." So goes the parable of the organizations who tried XP but it didn't work for them. Did you work in iterations? Was your customer available? Did you try to fix it when it broke? The answer is usually "No, there wasn't time for all that; we have deadlines after all." But all of XP working together makes a cohesive solution, and each part builds and supports the whole. Be careful about picking and choosing what you'll try. If everyone around you is raving about peaches and cream, and you try it but leave out the cream, you'll be missing out, and may give up on the peaches without ever knowing what you're missing.
Abide by the principle
Now that you've learned a few things to do, you need to do the things you've learned. Yes, you really do need to write a unit test for that piece of business logic you're about to hack into that class. I understand that it's a small change and this class isn't quite set up for unit testing and it may take you 25 minutes instead of 5 minutes to make the change. Daniel-san, abide by the principle: wax on, wax off.
The Karate Kid thought he was just doing a bunch of work for Mr. Miyagi, painting the fence, painting the house, sanding the floor, and waxing the cars. It was really frustrating for him: why do I have to do all this stupid work? I just want to do karate! But in order to learn to do karate, he had to do all the "stupid stuff" first. In fact, the stupid stuff was the path to doing karate. Daniel was very surprised after all the hard, tedious work was done to find he could block punches and kicks like an expert because of all the "stupid stuff."
Pursuit of mastery requires learning through experience, not just academic study. There are things that are too subtle to see without sharpening our perception through practice. So when the frustration mounts and you feel like quitting or compromising, take heart that you may be at the threshold of a meaningful step in your journey.
Warnings:
Now in The Karate Kid, Part III, Daniel gets a new sensei, Terry Silver, who is actually Daniel's enemy. Silver teaches Daniel bad techniques that are painful in the short-term and harmful for his long-term technique.
Silver meant harm; I know of no software development teacher who means harm. Nonetheless there are materials out there that mean well, but if you follow their teaching you'll experience pain in the short-term and have to deprogram yourself later in order to progress. It pains me to see the casualties of bad teaching engrained by years of use, and the technological fallout. Beware the false teachers; in your pursuit of good material consider what Jesus Christ says about false prophets: "By your fruits you will know them." His words have more wisdom than appear on the surface: fruit is not evident right away; it takes time to be manifested, and until it fully manifests itself it takes a trained eye to identify whether the fruit will be good or bad.
Dissolve the principle
Once you've learned some good techniques, obeyed them long enough to learn some of their more finer points, and given them time to bear some fruit to see whether you like the way it tastes, another important consideration remains: dissolve the principle.
Bruce Lee expounds with the following:
...In short, enter a mold without being caged in it. Obey the principle without being bound by it.
Lee invented Jeet Kune Do, a system of fighting that "works on the use of different 'tools' for different situations." Opponents using a single martial art may become predictable, forced to operate within his art's implicit limits. The principles of any one way give strength and have their utility, but come with limits, and for you to exceed those limits you must know the principle well enough to know when it is out of place, when to dissolve it.
Domain models are great and all the rage. Everyone should probably always use one, right? Martin Fowler in his great book gives four paragraphs describing when to use it (p119), one of the main criteria being "if you have complicated and everchanging business rules." How many of us have Customer.FirstName in our domain model? Is that really a complicated and everchanging business rule?
Everyone should always use a layered architecture, right? Does that necessarily mean we draw huge horizontal lines through every application? Are there other ways to obtain separation of concerns? Are there parts of my application where I'm actually limited by NHibernate?
As the old adage goes, and is oft repeated by software developers, if all you have is a hammer, everything looks like a nail. You can pound a screw into a board with a hammer, but it sure takes a lot of effort.
Warnings:
So does this last section sooth your conscience from those design decisions you didn't feel good about, where you didn't abide by the principle? Do not too quickly "tip the vessel of knowledge," and earn yourself an architectural boot to the head. The tendency of most of us is to quit the guiding principles too soon through impatience. Don't abandon the principle and think you're dissolving the principle. When you dissolve something in water, it's still there, it just no longer exists as a distinct thing; it becomes an integral part of something more than itself.
Comments !