Lesson:
A Dummy’s Approach to Agile Development
(or, “If You Can’t Draw It, Don’t Code It”)
I have an admission that I must make. While I have criticised authors like Scott Ambler and Craig Larman for pushing Agile development so forcefully in their books, I must admit that they are on to something. The problem, in my opinion, is that these authors present Agile development in such a monstrously complex way that it would only make sense to someone who has already used that development process.
Let me provide an example. Please imagine that motorbike racer Valentino Rossi has thundered down a racetrack’s straight, and is about to turn into the first corner. From Valentino’s perspective, the corner goes to the right. Which way does he turn the handlebars on his bike in order to turn right?
Let’s ask a nerd. “The front wheel of a motorbike at speed is a gyroscope that will roll about the output axis in opposition to the input axis.” So there you have the right answer. However, that description only makes sense to someone who has already experienced turning a motorcycle travelling at speed. For anyone who has not had that experience, the description is meaningless.
Let’s ask a teacher the same question. “A motorbike at speed is carrying a lot of momentum and, once it is going fast in a straight line, it will be very difficult to change its direction. Still, let’s say that Arnold Schwarzenegger is riding the bike, and has the physical strength to overcome the bike’s resistence to turning. Now, let’s say that he turns the handlebars to the right in precisely the same way as if he were on a pushbike travelling at 5kph. If he were on a pushbike, he’d turn the handlebars to the right. But on a motorbike weighing 150kg and travelling at 150kph, the front wheel (20kg) of the bike would go momentarily to the right, while the rest of the bike (130kg plus rider) will continue travelling straight ahead. The bike would literally trip over its own front wheel, just as surely as if someone had stuck a pipe through its spokes. Because the front wheel has moved slightly to the right, the bike would fall onto its left side, and Arnold will be nursing bruises for two weeks. What this means is that if the motorbike’s handlebars are turned to the right, the bike will fall to its left. If the handlebars are turned abruptly (as you would do on a pushbike), this will result in a crash. But if the handlebars are turned gently to the right, the bike will start to fall away gently to the left. Now, if the center of gravity of the bike is slightly to the left of its wheels as a result of this gentle falling, then the centrifugal force will mean that the bike steers to the left. The bike is literally falling gently into the corner. Hence, when Valentino approaches that right-hand corner, he will be push the right handlebar gently forward, which will momentarily turn the front wheel to the left, which will result in the bike falling to its right, and falling into the right-hand corder."
What does this illustrate? It illustrates that I have chosen a very poor example. But the point I was trying to make is that if you ask a nerd to explain something, you might get a technically accurate answer, but that answer will only make sense to someone who already understands the answer. To everyone else, it will be gobbledygook. To those of us who come into the software development profession from outside, and who therefore have no experience of any software development process, the technical descriptions of Agile development have us asking, “What the bloody hell are you on about?”
For those of you in the audience who will be nodding your head and thinking, “Thank God it’s not just me who doesn’t understand what those nuts are on about,” let me provide a Dummy’s Approach to Agile Development. This approach has the informal description, “If you can’t draw it, don’t code it.”
The Dummy’s Approach to Agile Development says that you should write down, in one sentence, what you need to do—what problem you need to solve. Examples from Charlie’s development would include, “Come up with a way to add data to a business object,” or, “Come up with a way to ensure only some users can view certain pages,” or “Come up with a way to present the same page but in multiple languages.”
The next step in this Dummy’s Approach is to research the topic a little, just so that you know what you’re up against. You don’t have to become an expert on the matter, but just know enough that you understand the basic issues.
Once you understand the basic issues, you can then break the problem down into smaller pieces. If you look back at my discussion of globalization, you will see that the basic problem of how to globalize a website breaks down to two smaller problems: find a way to get text out of the code and store it ‘somewhere else’, and then find a way for that text to be ‘brought back in’ when the code is running.
Break the problem down into as many small pieces as you can. For example, the problem for text to be ‘brought back in’ to the running application can be broken down into two further, but smaller, problems: first we have to ‘get’ the text that is stored ‘somewhere else’, and then we have to ‘sort out’ which bit of text to use.
Once you have broken the problem down into small pieces, take a piece of paper, and draw one square for each problem. Put each square anywhere on the page, it does not matter where. What that square represents is the class that solves that particular problem. This is a very simple relationship. For each little problem you have discovered, you will have one class that solves that problem.
Next up, give each square a name that looks a little bit like an American Indian name in Noun-Verb format. For this globalization example, names might be “TextSaver,” “TextGetter,” and “TextSorter.”
With a new sheet of paper, place the squares in some arrangement that shows which squares talk to which other squares. If one square needs to talk to another square, draw a line between those two squares. Work with this arrangement until you minimise the number of joining lines.
When you have arrived at an arrangement that looks good to you, consider how these different squares will talk to each other. Do they pass simple messages (“Give me the text for a SaveButton”) or do they pass complex messages (“For an authorized user that is in the Administrator role, give me each of the pages that he can edit”)? If the message is complex, draw a circle that will represent the passed message. Consider this to be like the ball that is passed between players in a game of sport. The ball will end up being another class in your application.
You may be thinking, “Well, that sounds easy enough when you’ve made up an example, but real-life is not that easy.” You are perfectly correct. The first diagram is almost sure to be a rough guess. If you have a few doubts about what the diagram should look like, or what squares and circles you might need, then go back and research a little more. Even if you re-read the same stuff, you will now have a reference diagram so that you can see where new pieces might fit.
The idea is that you read a bit, draw a bit, read a bit more, draw a bit more, back and forth until you arrive at a diagram that feels “right”. It doesn’t even matter if the diagram is right or not. What matters is that it feels right to you, and that it provides a map of what you actually need to code. Did I really just say that it does not matter if the diagram is right or not? Yes. You see, there is no such thing as “perfect” code, so it’s pointless to strive for it. Without perfect code, there’s only two types of code: crap code and good code. This Dummy’s Approach is a way to ensure that ours is always good code, and never crap code. Unless you’re involved in launching rockets to the moon or controlling medical apparatus, then good code is good enough. The time it would take to move the good code to excellent code would be time better spent with your family or friends.
Once you have your final diagram, you can fire up your text editor or IDE and actually create the code for those classes.
Is this a long way to go about creating code? No! It is the short way. If you follow this process, then you will know precisely what classes you need, and what those classes must do—so you will code by knowing. If you do not follow this process, you must guess at the first class you need, then have a guess at the second class you might need, then have a guess at the third class you might need, then change the first class because it is wrong, then remove the second class because it is now useless, and so on—you will code by guessing. In the process of creating Charlie, I have used both approaches. I can tell you honestly that the components I first illustrated on paper are still in Charlie. The components where I just “had a go” have been ripped out of Charlie. I cannot overstate the importance of describing the problem, then researching and drawing, researching and drawing, back and forth, and then, only then, finally coding.
Is this really based on the Agile approach? Who cares! Let me just say that this approach has been the basis of everything that has gone right with Charlie. Research and draw. Research and draw. And if you can’t yet draw it, don’t yet code it. Research more and draw more. When you can draw it, then you can code it.
by Alister Jones | Next up: Silently into the Night →
----
Alister
I have met you at your blog last Friday (the last working day of the last year) and this entry made my day!
I have read all the entries so far (I don't know how many was) and your efforts to publish not only the solution but how do you got there is remarkable !
Congratulations
Post a Comment