links for my agilenorth 2010 session
At AgileNorth last week I was asked at the last minute to fill a vacancy left by a speaker who couldn’t make it. I cobbled together a session about “flow”, one of the underlying principles of Lean Thinking, and therefore also of agile software development. Here are a few links to materials and references I should have given at the time:
- My slides are now up on slideshare. Sorry, there are no notes.
- I talked a lot about The Goal by Eli Goldratt; this book is pure genius, and a must-read for anyone interested in improving the productivity of their organisation.
- We discussed the idea that the flow of value through an organisation is limited by exactly one constraint. A wonderfully simple illustration of this can be found in Kevin Fox’s short Blue Light story. Well worth a read.
- I talked a lot about Kent Beck’s paper Continuous Deployment Immersion, which I mistakenly titled “You’d Have to be Crazy to Try This”. I think this is a really cool idea — not because you need to deploy each line of code separately, but because you need to be good at deploying and good at slicing your market offering thinly.
- I mentioned various practices of eXtreme Programming, including YAGNI, OnsiteCustomer, FrequentReleases and ContinuousIntegration; all of these are needed as you attempt to increase the flow of value by reducing your development batch size.
- I mentioned MMFs — “Minimum Marketable Feature-sets” — as being one way to work with the market to define your smaller batches.
- I mentioned that one of the key difficulties in reducing the software batch size is the acceptance and understanding of emergent design.
I talked about a lot of stuff; please let me know if I’ve missed anything important here.
I’ve also set up an agilenorth2010 tag on del.icio.us to collate the online materials from all the other speakers, as I find them. Please tag anything you find that’s relevant from the day, so it’s all in one place.
“from chaos to kanban” now online
I recently co-authored a paper with the developers at Codeweavers Ltd in which we describe their two-year journey from complete chaos to a highly evolved kanban-style software process. The paper has been accepted for XP2010, and you can now get the PDF from the Codeweavers developer blog. Well worth a read, because it shows in detail the team’s gradual transition using simple inspect-adapt steps. (Paul and Craig also presented the paper at AgileNorth2010 and received a lot of interest and positive feedback.)
interviewed on railscoach
Filed under: reek, refactoring, ruby, tdd | Tags: tdd, ruby, refactoring, reek
Leave a Comment Charles Max Wood has just posted an interview he did with me a couple of weeks back. It’s about Reek, Refactoring in Ruby and agile development practices.
I waffle too much, and make a couple of historical mistakes. Ho hum.
releasing vs delivering
Here’s a quick thought that you might like to use in your next retrospective: Do you know that the software you just released has realised the expected value?
What if the answer is that you don’t know? How could you find out? And what might be the positive or negative side-effects of going to find out?
Here’s another way to look at the same question: Do you deliver more value by moving to the next story/MMF, or by helping the current story/MMF to release its full potential? Is there a single answer for your software/service? If not, what factors or conditions would cause the answer to change?
value objects and “equality”
Filed under: designpattern | Tags: design patterns, value object
Leave a Comment Today Corey Haines posted another great video interview with JB Rainsberger. This time the topic under discussion was Value Objects. Well worth a listen (go ahead, I’ll wait).
The main gist of the discussion was JB’s assertion that the distinguishing feature of Value Objects is that their equality depends on their state, as opposed to depending on their identity. Thus two 1-Leu notes are “equal” if and only if they have the same monetary value, even though they have different identities (for example, their serial numbers differ). JB then proceeded to extol the virtues of imbuing Value Objects with an equality function and I agree, but only up to a point.
I don’t doubt that creating a new Value Object class to wrap a primitive yields many benefits, and in many cases one of those benefits is to allow the writing of an equality operator for that new class, thereby simplifying much code. But right now, this week, I’m in the throes of a refactoring whose sole purpose is to allow the removal of such an equality operator, because two different views need to compare these values differently.
Going back to real money for a moment, suppose two people looked in their wallets and discovered they had the same amount of money. Does that make their wallets “equal”? I’d say it depends on who’s asking, and why; you might be comparing for total value, whereas I might compare for total number of notes, for example. It doesn’t really make sense for wallets to have an equality operator, and yet in many respects they are interchangeable Platonic values.
That’s a bit contrived, but I do think it’s generally the case that objects with a multi-dimensional value can have multiple valid “definitions” of equality — and that therefore, in such cases, equality is in the eye of the beholder. Does that invalidate JB’s argument? No, I don’t think so. The various kinds of “equality” of objects with a multi-dimensional value still satisfy his definition, and they are still value objects. I’m just being a pedant. Again.
“primitive obsession” or “open secret”?
Yesterday Corey Haines posted yet another great video interview with JB Rainsberger. This time the topic under discussion was the Primitive Obsession code smell — what it is, how to recognise it, why it is a problem, what to do about it, and what you’ll see when you’ve fixed it.
I agree with JB — this is a difficult concept to communicate when teaching, and I think part of that comes from the name Primitive Obsession. In fact, after a vast amount of deliberation, Bill Wake and I proposed the alternative name Open Secret in our book Refactoring in Ruby. Our reasoning is that, as JB points out in the video, the essence of this smell is the fact that the lack of an encapsulating abstraction pushes knowledge and responsibilities and behaviour out into the open; whereas the representation of that knowledge should be a secret. It’s not so much the primitives that are the problem, but that they represent a domain abstraction — and that one chosen representation of that concept is visible to, and necessarily understood by, all and sundry.
Does that rename help explain this code smell?
microtests for exceptions
Over on the Dev@Pulse blog Jim raises some interesting points about how and when to microtest the messages in thrown exceptions. Jim’s discussion got me thinking about how I solve the same problem myself, and on reflection I discovered I use a slightly different tactic than Jim’s:
I write one test for each important piece of information that must be conveyed by the exception. For example, there might be a test that checks the exception’s message for the incorrect business value that caused the error; and maybe another that checks for the name of the throwing object. Etc etc.
Here’s a simple example, based on some of Reek‘s microtests:
context 'when the parser fails' do
before :each do
@parser_error = 'Error message'
parser = mock('parser')
parser.should_receive(:parse).and_raise(SyntaxError.new(@parser_error))
@source_name = 'source/file/path.rb'
@src = SourceCode.new('def unused() end', @source_name, parser)
end
it 'raises a SyntaxError' do
lambda {@src.syntax_tree}.should raise_exception(SyntaxError)
end
it 'reports the source name' do
lambda {@src.syntax_tree}.should raise_exception(SyntaxError, /#{@source_name}/)
end
it 'reports the parser error message' do
lambda {@src.syntax_tree}.should raise_exception(SyntaxError, /#{@parser_error}/)
end
end
This scheme has two advantages: First, there are fewer direct dependencies on incidental text in the error message, which means the microtests are less brittle, and hence less likely to be affected by simple changes of wording. And second, the tests clearly indicate which parts of the error are “important” – so if one of them later fails I get a reminder that I’ve lost information, and thus a gentle prod to re-consider the most recent code change.
Everyone writes code that throws exceptions, so I’m sure these aren’t the only tactics for microtesting them; what do you do?
extract class or substitute algorithm?
I have a dilemma. In fact, I frequently have this dilemma, so I thought I’d ask your opinion on which way you would address it.
I just completed a CRC session for the next feature I want to add to my codebase. One of the classes identified for the new scenarios is a particular kind of counting collector, and I realised that the same behaviour already occurs elsewhere in the codebase. So one of the first steps in coding up this new scenario will be to extract a new class from an existing class. The existing class has reasonable micro-tests, and therein lies the dilemma:
- I could simply use the Extract Class refactoring recipe, and I’d be done quite quickly; the new collector class would be tested indirectly, via the micro-tests for the original class (which would now be the extracted class’s only client).
- Or I could develop the collecting class test-first, from scratch, so that it had its own micro-tests, and then use Substitute Algorithm, reimplementing the old class to use the new.
The advantage of the second approach is that it gives me precise micro-tests of the new class. But while developing that class, I could drift away from the required usage, or I could make it harder to switch the original class over to using the new one. (I tend to think of Substitute Algorithm as being riskier than Extract Class.)
So which is better — use Extract Class and know that I have a working client-supplier relationship; or TDD from scratch and risk going off track? In practice, I tend to choose Extract Class if I’m feeling lazy or distracted, whereas I go with TDD followed by Substitute Algorithm when I’m feeling organized; in the latter case I usually get stressed by the “substitute” step…
(It seems to me that if we choose the latter approach in general, many refactorings should cease to be used. That can’t be right, can it?)
fixing Feature Envy by backtracking
After a conversation this week with Hugh Sasse about Feature Envy and Utility Functions, I realised I’ve evolved my approach to dealing with them:
When Reek tells me about one of these smells, my first step is to inline the smelly method back into all of its callers. Then I look for ways to fix the resulting duplication without extracting the same method again. Sometimes the re-formed methods break apart in new ways (compared to when they were first written), other times I see opportunities to peel off new classes. (One thing I never do these days is to introduce inheritance relationships in order to remove duplication; I look hard for ways to solve it through delegation, often to a new class, or I leave the duplication in place for the time being.)
This approach seems to be working well for me at this early stage. Have you tried this or something similar? How did it turn out?
communicating intent is all about names
Filed under: Uncategorized | Tags: refactoring, simple design, xnf, xp
Comments (1) Ths ten-minute video chat between Corey Haines and J.B.Rainsberger introduced a nice simplification of eXtremeNormalForm.
In the discussion, JB hardens up the wishy-washy Communicates Intent value by noting that it’s just about “bad names”, and here’s why. In an OO language, “communicating intent” boils down to breaking the system into small pieces and giving them good names, names that resonate with the design and the domain. Small pieces are no good on their own, and good names for bad ideas will soon be weeded out. JB therefore claims that good design (he says good architecture) boils down to
- eliminate duplication
- eliminate bad names
(He takes passing all tests – ie. correctness – as a given, and he says that eliminating duplication and bad names also renders the software “small”. I disagree on that last point.) So, his assertion is equivalent to saying that every code smell is a symptom of either Duplication or Bad Names, which I find easier to explain than asking people to ensure that the code “communicates intent”.
