Archive for the ‘conference’ Category
Corrigendum to Lightning Talk at Agile Mancs 2016
Wrong Theorem
We’ll see on the video, I guess, but I think I said “Mean Value” when I should have said “Central Limit”. My mistake. It had been a long day, and they were handing out beer.
On the β-distribution
If you are going to try that sort of Monte Carlo estimation for yourself you don’t need to wrestle with the full-blown β-distribution, which is a bit of a beast. You can approximate it well enough using a triangular distribution. The base of the triangle is the closed interval—time, money, whatever, I’ll talk about time—between, as Dan North suggested, that time which if the work took less than that you’d be very, very surprised and that time which if the work took much longer you’d be very, very embarrassed. Somewhere in that interval—and very rarely in the middle—is the time that you think it’s most likely for the work to take* and the apex of the triangle lies above that point. The altitude of the apex must be such that the area of the triangle is 1.
Have fun!
Getting to not having to do any of that
Being asked for a estimate is, it’s true, a sign that your interrogator doesn’t trust you.
Usually this is not because they are monsters who relax every evening with a well-thumbed copy of The 48 Laws of Power and a small glass of chilled kitten’s tears. Usually it’s because, firstly: they have suffered a long history of paying people to develop software for them and not getting much back in return, and secondly: they don’t know you from Adam or Eve.
In a better world, they would trust you, because your heart is pure and your intentions good and wouldn’t if be great if we could all just get along? And it would.
Until that world arrives we will have to deal with suspicious, hard-bitten CFOs who have a keen understanding of their fiduciary duty. They—or their subordinates—will ask you for an estimate. Some of them will want then to interpret your estimate as a commitment, perhaps with contractual remedies for failure to meet same, and so hold your feet to the fire to deliver exactly against those estimates. I strongly recommend not doing business with the ones that cleave tightly to such a position. They are setting up themselves, and you, for failure.
But many will be amenable to understanding that, as McConnell says, the point of estimation is not to predict outcomes but to see if you are in with a chance of managing your way to success.
How to break the cycle?
Deliver value. Early, often, reliably. Very early, very often.
With contemporary engineering practices and tooling this can now often be done very quickly. Even in those “heavily regulated” environments. When you have—and maintain—a reputation for delivering value then your conversations with the people who’re paying you to do that change dramatically. From: “how much will X cost?” To: “how much do I need to pay to have you keep on doing J, P, R, S, Q…?” That’s much more agreeable for all concerned.
Stepping back
YMMV, but I’ve found, while doing and managing software development work in and for VC funded local startups, publicly traded global blue-chips, privately owned product companies, government departments and many other scenarios, on four continents, that when something about the scenario says “new”, whether it’s that you are a new supplier, or they are a new CFO, or whatever, then requests for estimates—maybe with some story about “just for budgetary purposes” attached—will come; but once a reputation for reliable delivery of value is established they fade away, until something changes that takes us back to “new”.
It would be nice if we didn’t have to erect this infrastructure of estimation every now and again, and you can if you wish refuse to work under such terms—you may then find work unpleasantly hard to come by—or you can invest in re-educating people not to ask those questions—but the first rule of consultancy is not to solve a problem you aren’t being paid to solve—or you can roll with it, demonstrate the simple lack of necessity of estimation in an effective organization and wait for the next cycle which often will be less severe than the previous one. And so on.
Good luck!
* Whenever you are asked for an estimate, for anything, you should reply with at least these three numbers—or their equivalent—and if that shape, never mind the content, of answer is not acceptable then you have discovered that you were not being asked for an estimate.
TDD as if You Meant It at XP Day London 2011
Attendees, please add your thoughts, and links to your code repo if you wish, as comments to this post.
Thanks.
TDD as if you Meant It
What’s the problem with TDD?
TDD is quite a simple process. Beck Describes it here in these terms:
TDD
- Add a little test
- Run all tests and fail
- Make a little change
- Run the tests and succeed
- Refactor to remove duplication
This turns out to be a hard thing to do. My observation has been that the more experienced and fluent a programmer someone is the more difficult it is for them to stick to this process. What tends to happen is more like this:
Pseudo-TDD
- Think of a solution
- Imagine a bunch of classes and functions that you just know you’ll need to implement (1)
- Write some tests that assert the existence of (2)
- Run all tests and fail
- Implement a bunch of stuff
- Run all tests and fail
- Debug
- Run the tests and succeed
- Write a
TODOsaying to go back and refactor some stuff later.
Really good programmers can get away with this, for a bit. But even during that early period I think they are missing a trick. A couple of tricks, in fact.
Firstly, in the pseudo-TDD steps 1, 2 and 3 can take a long, long time. Tens of minutes perhaps, hours, or days even. This is time during which you aren’t running tests, aren’t getting feedback and aren’t learning anything. Step 7 must be assumed to take an amount of time unbounded above.
Secondly, in the Pseudo-TDD process the programmer must fall back on some technique for making design decisions and somehow getting them right exactly at the time when they know least about the problem and its solution. In TDD we have the advantages of evolutionary design: we can discover a good-enough design and then incrementally improve it. I think it is really hard for people who know themselves to be good programmers to let go of the design process in this way.
TDD as if you Meant It
I began to wonder if there was some sort of exercise that folks could do, in safe controlled conditions, whereby they could experience the odd and surprising (and delightful) things that can happen when you really do TDD, as Beck describes it, with the hope that the experience would carry over to their daily work as programmers.
This would be a pair-programming exercise, since it’s often easier to maintain a level of discipline if you know someone is watching you can provide friendly, constructive feedback.
The problem to be solved should be simple enough that decent progress can be made on it during a typical conference “workshop” session (say, 90 minutes to 3 hours) and also have an obvious solution that experienced programmers would want to jump to implementing.
In the first couple of presentations of the session I used a problem from the game of Go. This worked reasonably well but I feel I spent too long explaining the game. Some folks who have picked the exercise up have used tic-tac-toe with good results. I tried that myself at NDC 2011 and was quite pleased with the result. From now on I will use that problem.
Another description of TDD is due to Bob Martin. It goes like this:
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
I took these rules as a starting point and then tried to produce stronger rules that would force the programmer (pair) to allow the design to evolve. I don’t think I’ve yet landed on the best set of rules, and people report difficulties with various part of it, but if I were going to do the workshop today these are the rules I would enforce (subject to change and refinement at any time, last updated 3 Sept 2011):
The Rules
- Write exactly one new test, the smallest test you can that seems to point in the direction of a solution
- See it fail
- Make the test from (1) pass by writing the least implementation code you can in the test method.
- Refactor to remove duplication, and otherwise as required to improve the design. Be strict about using these moves:
- you want a new method—wait until refactoring time, then… create new (non-test) methods by doing one of these, and in no other way:
- preferred: do Extract Method on implementation code created as per (3) to create a new method in the test class, or
- if you must: move implementation code as per (3) into an existing implementation method
- you want a new class—wait until refactoring time, then… create non-test classes to provide a destination for a Move Method and for no other reason
- populate implementation classes with methods by doing Move Method, and no other way
The member of the pair without their hands on the keyboard must be very strict in enforcing these rules, especially 4.1 and 4.2
After some respectable time coding, contrast and compare solutions. Consider the classes created. How many? How big? What mutable state? Consider the methods created How many? How long? Apply a few simple design metrics. How was the experience of working this way different from the usual? How could these ideas be applied in your day job?
Experiences with the Workshop
If you haven’t tried the workshop yet, and would like to, you might want to stop reading now so that you don’t lose the “a-ha!”. That is to say: spoiler alert!
Mine
This is a tough exercise for experienced programmers and doubly so experienced TDD practitioners. I observe that pairs including folks who are not full-time programmers (BA’s, testers, managers even) do much better.
I’ve come to recognise the point about 5 to 10 minutes after the start of the exercise proper where everyone quietens down and seems to be making progress. At this point I stop the exercise and ask who has (in the case of tic-tac-toe, say) created a class called something like Board with something like a 3×3 array of ints in it (or even better, of an enum with members like BLANK and X and O) and no tests for it. After a bit of cajoling it always turns out that several pairs have. Because they “know” they will “need” it. Or because without that class they “can’t write any tests”.
At this point the facilitator needs to be strong and force them to delete that code and start again. Yes, really.
It’s extraordinarily hard for some pairs to get going. Often it’s the ones who have just had their code deleted. They will just sit and stare at an empty editor window. This is the crucial learning step. If they are not allowed to write tests about the solution that doesn’t exist yet, what are they allowed to write tests about? There is only the problem. Here is where we start to see the connection between TDD, BDD (in so far as they are not identical—hint: they are identical) and DDD and eDSLs.
There is always a startling variety of solutions.
Some pairs can implement pretty much a whole tic-tac-toe game playing program without a class remotely like a Board.
Others
At least these people have kindly written up their experiences of doing the exercise:
- The first outing for the exercise was at Software Craftsmanship 2009 and Gojko Adzick did an excellent writeup of that and then tried running the exercise himself
- Rob Bowley has done the exercise a couple of times and shares his thoughts on it
- Mark Needham used the exercise (with rock-paper-scissors as the target) in a code Dojo over two weeks, with various observation in week 1 and week 2 and as a more extended exercise himself
Those are just the ones I know about. I’d love to hear about more.
cumulativehypotheses 