On boolean externalities

This week @avdi wrote a really interesting blog post in which he expounds the woe induced by trying to debug a stack of methods that return booleans to each other. I couldn’t get Disqus to load on the post itself, so my response is below. Go ahead and read Avdi’s article now; take your time, and think about what you would change in his code; I’ll wait here until you’re ready.

A lot of the comments on That Twitter suggest that this can be “fixed” by returning things that are more complex than simple booleans, including switching to a different language to make that easier. I think most of them are missing the point. I think this is a representation problem. Let me explain.

The code as it stands uses several booleans — I counted around six, and I suspect there are more in the code branches we weren’t shown. In order to figure out whether the user is allowed to view an episode, the code effectively rummages through the user’s past, looking for a confluence of events that combine together to give the user that permission. And so when the code doesn’t do what was expected, poor Avdi then has to do the same, only using the debugger or logging statements. The problem therefore, it seems to me, is that the current state of the user is only represented indirectly.

It seems to me that this code breaks the second rule of Simple Design, in that the domain is not represented faithfully by these booleans. I would be willing to bet that not every one of the 2n possible combinations of values of these booleans is possible. Indeed, it seems likely that there are only a handful of states in the lifecycle of a user. So to use a group of booleans to represent these states is to misrepresent the structure of the domain: The representation permits many more possibilities than can actually occur, and leaves the job of figuring out the current state to a bunch of other methods scattered through a couple of different objects. Another way to express this might be to say that the code shows Connascence of Meaning (or Algorithm), because numerous methods need to know something about how the user’s state is represented.

So my solution would be to create an explicit state transition model for users, and then to represent that in the code using a state field on the user. It would then be possible to produce errors such as “User X cannot do Y because s/he is in state Z”. It also opens up the possibility of using the State pattern, so that the user would hold a reference to an object representing its current state. Such an object might know how and when the user arrived in this state, and have code that validates the user’s state changes. It might even provide the valid onward transitions as, say, Command objects.

So that’s my approach, and I’ve been finding it more and more useful recently to solve modelling problems such as this. The question is: is this applicable in Avdi’s case; does the code we haven’t seen support this design…?

Advertisements

the anti-if campaign

I’ve just signed up to the Anti-If Campaign (link via Dave Nicolette). This is a movement to promote the use of strong object-oriented software design principles, by asking us to think twice before we allow any conditional branches into our code. This isn’t dogma, just a hook that can help direct our refactoring.

Long-time readers of this blog will know that I believe most conditionals to be duplication — see the following old posts for examples of my arguments here:

I’ve placed the Anti-If Campaign’s badge on my sidebar to show that I look hard at every conditional, and I invite you to do the same!

carnival of the agilists, 9-nov-07

Welcome to the latest edition of the Carnival of the Agilists, the blogroll that skims the cream from the top of the agile blogsphere. This week’s theme is: a bumper bag of liquorice allsorts

Brian Marick has posted the transcript of his OOPSLA talk in several parts. Part 3 discusses Pasteur’s attempts to educate the French about the causes of anthrax, and relates that to a fun idea for energizing daily stand-up meetings: “another example of using a weirdo theory from sociologists to give myself ideas.” Meanwhile Mark Levison has revived his team’s iteration boundaries by introducing good agendas: “By breaking things down into smaller more focused chunks the new agenda (and prompting questions) has made our retrospectives more valuable”. Dale Emery also chips in on the subject of efficiency, with a great discussion of the causes of multitasking: “If I split my time among all six tasks, I get to tell all six people every day that I’m making progress on their important tasks. And I get to be sincere about that”. (I have no idea why this post appeared in my RSS reader this week, as it was written over two years ago. Still, it fits here and its still very relevant today; think of it as this Carnival’s “Two Years Ago This Week” entry…)

Both Mark Levison and Dave Rooney discuss the downsides of working remotely from the team. And while Mark (and his commenters) provides a list of tools and techniques to help improve communications, Dave’s top tip is: “Remind your significant other that hay and shavings from the rabbit’s cage shouldn’t be washed down the drain in the laundry room.”. Now why didn’t that practice make it into the white book?

Rebecca Wirfs-Brock reports on the findings of a workshop that discussed Challenges When Communicating Designs: “I started by making the connection between telling others about designs and storytelling. Effective designers need to tell good stories. And the tone and means by which we communicate design ideas should vary depending on the reasons we have for telling a particular story, and our audience’s background and expectations”. Now I think about it, the great developers I’ve worked with are all great story-tellers too; Rebecca’s discussion suggests that’s no coincidence.

Michael Feathers’ latest addition to the Beautiful Code blog is a post entitled Elegant Byte Counting, which centres on the use of the SpecialCase pattern to solve a tricky little code duplication problem: “This is a particularly elegant way of handling things. Rather than having separate code to traverse writable things for size and write, all of the work can be done with the same piece of code, the write method. There’s less duplication and less possibility of error in maintenance.” There are nowhere near enough of these great little design vignettes around, in my opinion.

After the summer-long debates about certification of various sorts, Willem van den Ende has discovered that you’ll make more money if you are not certified. He quotes Mark Gallaher thus: “A new report from industry research firm Foote Partners LLC finds that the average pay for noncertified IT skills topped that for certified professionals […]”. Less is more, it seems.

And finally…

The calls-for-participation have been published for both Agile 2008 and Scotland on Rails. Give them a look and submit a few sessions — I know I will!

To suggest items for a future carnival – especially from a blog we haven’t featured before – email us at agilists.carnival@gmail.com. As ever, this and all previous editions of the Carnival are catalogued at the Agile Alliance website. Look out for the next edition of the Carnival around the end of November, hosted by Pete Behrens.

pseudo-OO

In Pseudo-OO Design Dadi Ingolfsson talks about that all-too-common phenomenon – a design in which the code and the data are separate.

“This relates to the Microsoft-style of a DAL (Data Access Layer), a BLL (Business Logic Layer) and a UI, where the data that travels through the layers might be, for instance, dumb Customer objects or DataSet objects. The objects in these different layers are very procedural in nature as they usually only operate on data in objects that are sent to them rather than the data being their own. It´s what Fowler called an Anemic Domain Model. This is not OO design even though many programmers seem to think code is OO if it has classes and objects.”

By coincidence, this week I found myself workshopping agile programming with a team whose legacy C++ system is just like this. My approach to gradually improving the situation is to look for instances of the feature envy smell. Bit by bit, as we find each of these smells, we move the code into the objects where it belongs. Bit by bit, encapsulation improves. Bit by bit, the domain model emerges in the code. And very often, as we introduce abstractions to improve testability, bit by bit a hexagonal architecture emerges too.

Why is this important? Why is it bad to separate the code from the data? Because it stops the code changing at the pace of the business. Distributed behaviour and state mean that each piece of business knowledge is also distributed throughout the system. Which means that any new or changed requirement will cost more to implement.

object thinking (revisited)

For years now I’ve been looking for that one book that would provide good background reading material to help teach object-oriented software development. Currently I’m reading Extreme Programming Adventures in C# by Ron Jeffries, and I think this book comes closest to fitting my needs. I’m sure not everyone will appreciate the very informal style, in which Ron takes us along for the ride while he develops a new application and learns a new language. But I find the lessons he learns along the way – and the development process he promotes – fascinating. I have yet to find a better introduction to object-oriented design and development.

object thinking

I really must get around to reading Object Thinking. It gets a reasonable review from Darrell Norton among others, and Andy even uses it to support my own metrics!

When it comes to coaching teams in object-oriented design, I’ve always had trouble finding good reading material to give out. Books I’ve tried include:

  • Bertrand Meyer’s Object-Oriented Software Construction. Back in the early nineties this was just about all that was available. While it does emphasise the behavioural view of objects, the use of Eiffel doesn’t help, and there’s little help with concepts such as refactoring or the need to eliminate duplication.
  • Rebecca Wirfs-Brock’s Designing Object-Oriented Software. I’ve always liked this book, but for some reason British Java programmers never seem comfortable with it. And again, it has little to say about code structure or quality.
  • Kent Beck’s Smalltalk Best Practice Patterns. This is my favourite of the three, because the patterns directly apply to refactoring code into great designs. But again, I’ve found that Java programmers seem scared to death of reading smalltalk.

Is Object Thinking what I’ve been looking for? Or is there another book out there that can show talented programmers what great code looks like?

Update, 9 may 05
At last, I’ve found a very good candidate!