Agile Software Process Improvement

Executable Acceptance Tests Could Drive Development Rather Than UI Mock-ups

 

Gojko Adzic is a jolly nice chap who offers some jolly sensible advice about how we can use acceptance tests to act as executable specifications - described entirely in business terms - to drive the design and implementation of our software.

He's dead right, of course. So right, in fact, that maybe he doesn't know how right he is. I would advocate going that extra step further in this approach: I would design and implement the logic of my example before I even think about user interface design.

Acceptance tests captured using a tool like FitNesse, for example, could specify the behaviour of the business services layer of our multi-tiered applications. It is possible to use these executable tests as a surrogate user interface, allowing us to explore and implement the business logic of user interactions and user workflow without so much as a text box being drawn.

These logical interaction specifications can then be used as a formal basis for UI design so that users can execute the same workflows through a friendlier, snazzier, sexier interface.

Over lunch I mentioned this as a possible approach, to which my colleague David quite rightly pointed at that most users need a visual UI model to help them understand the underlying logic. He's damn right, of course. Users need some way to visualise complex behaviour, data and rules. We share a semantic understanding of standard UI technology - forms, buttons, text boxes, drop-downs, grids and so on. We know what they are, and we generally know what they can do. So we can describe system behaviour in terms of the internal conceptual model of the user interface we share.

The problem with this approach, though, is that we have a tendency to get attached to the first design we come up with. So when we present users with a UI design in order to explore the requirements, we've actually jumped straight to a solution before we've had a chance to explore and understand the problem. And we often get stuck with that first naive design, leading to some very bizarre, counter-intuitive and clunky applications.

But there are other ways to visualise information systems. You can implement search algorithms using cards and filing cabinets, for example. You can create a working library system using books, boxes, paper and pencils. I'm a big fan of this kind of tactile modeling, where we collaborate using tangible, visible objects to explore the logic of our systems, getting the system to work in some mechanical form before we think about how it be implemented best as software.

In this sense, we can be deeply domain-driven, immersing ourselves inside the systems we're trying to model and effectively playing the role of the internal workers (processors) who execute the information workflows. Document that understanding with photographs and videotapes, and it could neatly feed into the kind of executable specifications Gojko talks about.

I've never put the two practices together, though, so I'll be very interested to find out how it would work for real. I suspect it would work just dandy, though.

Which is nice.

ASP.NET Encourages Procedural UI Coding?

 

I mean, why don't we just go back to writing our applications in FORTRAN?

The concept of an object oriented framework for implementing web user interfaces seems to have eluded Microsoft yet again. As always, it falls just short of allowing us to write the kind of neat, OO code we'd like to and drags us back down into the depths of magic strings and magic numbers and all manner of procedural nastiness.

The problem is that we can't do smart things like attach references to internal application objects to our UI components which are persistent across multiple user requests. Of course, web applications are supposed to be stateless, so you'd have to do something under the covers to map an object reference in view state to the actual instance it refers to (say in session or applictaion state), but is that really asking too much to have the framework resolve those references for us?

I just led a poor pair of developers down a blind alley, thinking - in my usual naive and techno-illiterate way - that ASP.NET would allows us to easily associate a concrete command object with a list item in a drop-down box. It transpires I was talking bollocks. (No, really, it does happen from time to time.)

We found ourselves tied up with magic keys and magic text values, and having to look up the command instance we want from a dictionary; and suddenly I'm having COBOL flashbacks.

It sucks. So here's a tip for web UI framework developers: having knocked up a couple myself, I know that you will want some transparent way to resolve references between your application's objects and UI framework objects. And I know you'll want it to work with your session state management solution. That's a given if you don't want to end up regressing to the days of prehistoric coding where the user clicked a button and we used the index of that button to look up the name of the object that handles that event. That went out with Visual Basic 1.0, didn't it?

Obviously not :-(

Another Post-Agile Job Advertisement

 

"Significant experience using the Agile, XP and post-Agilism development framework"

(From http://www.mima.org/jobs/index.asp?jobID=2103 )

So they're looking for a project manager with experience of constructive anarchy, then?

Good luck with that one.

Freelancers Are People Too

 

It's a fact of life that the majority of people writing code for a living are freelancers.

Employers like freelancers because we are flexible, we take responsibility for our own careers and general well-being, and we tend to hit the ground running on projects because - well, because we jump more often and have had more practice at landing on our feet.

Employers don't like freelancers because we cost a bit more - though they often underestimate how much their permanent staff are really costing them in taxes, sick pay, benefits and other hidden costs.

They also don't like us because we're more self-directing and have our own values and our own goals. There might be a bit of evolutionary psychology at work, in so much as they view us as outsiders, while they see permanent employees as members of their tribe.

There's a tendency for people who opt for permanent employment to get some special consideration over their freelance colleagues. Take staff surveys, for example. A client of mine once ran a staff survey that was not open to freelancers. We had not earned the right to a voice in the organisation.

But in this case - and in many IT organisations around the UK - freelancers made up the majority of the workforce. So this is a staff survey that ignored the opinions of the majority of the people doing the work. It was a kind of apartheid, in the sense of a voting minority dictating policy for a silent majority who lacked some of the key rights and freedoms of their permanantly-employed counterparts. But these freelancers weren't going away. Try as they might to attract permanent staff, they will always be mostly reliant on freelancers to get the work done. Software is a freelance business, after all.

On a film set, the vast majority of poeple working there are self-employed and work on a project-by-project basis. Should we not care what the actors feel because they're freelancers? Should we not solicit the opinion of the director of photography because he's paid through a limited company? Of course we should care what these people think. the film won't get made without them. In most IT departments, software and systems won't get delivered without freelancers working side-by-side with permies.

To disenfranchise one group because they've chosen a more flexible contractual arrangement and take more responsibility for their own welfare is, I believe, potentially misjudged. In the case of that client, there were freelancers who'd been with them longer than many of their permanent staff. Their contribution to the organisation is valuable, and for that I believe their stake in it was every bit as valid.

This industry is just too volatile and unpredictable to work without freelancers.

Conservation of Difficulty

 

Scientist, author and husband of the Lord President of Gallifrey, Richard Dawkins, wrote about his Law of Conservation of Difficulty. The jist of it is that obscurantism in an academic subject expands to fill the vacuum of its intrinsic simplicity.

Quantum Electrodynamics, for example, is a genuinely difficult subject. Other, perhaps less challenging, disciplines - and let's not name them here - conceal their lack of content behind a smokescreen of deliberate obscurity.

One wonders if the law might also apply to the complexity and/or obscurity of software designs. Over the years I've noticed that, while developers dealing with genuinely challenging problem domains often strive to simplify as much as they can, other developers working on much simpler applications can tend towards gold-plated, future-proofed solutions with bucketfuls of factories and strategies and builders and bridges and commands and visitors and all manner of concepts that bear little if any relation to the problem at hand.

What do you think?

Dependency Rejection

 

One of the risks in being helpful - in any useful or practical sense - is that you can wind up creating a dependence on your ability to solve other people's problems.

If you fix the build for someone, then there's every danger that the next time their build breaks, they'll come to you to fix it again. If you solve a design problem - like how to map a complex or derived association using Hibernate - then the next time they have a fiddly bit of O-R mapping, they'll be knocking on your door.

And in the longer term, by stepping in and fixing things for them too readily, you're not doing them - or you - any favours. I dated a girl when I was 16 whose mother washed and ironed all her clothes. Whenever she needed her pink blouse or her 501 jeans or her Frankie Goes To Hollywood t-shirt she would go to her Mum. And if her Mum was busy, or not there, she would stamp her feet and get very frustrated. It never, ever occurred to her to stick any item of clothing in the washing machine or run an iron over it herself.

When she got to university, she had her boyfriends wash and iron her clothes, I was reliably informed. And I heard gossip recently from an old school chum of hers that her husband does all the laundry in their house. I wonder if he'll teach the kids to do their own washing and ironing?

Anyway, I digress. As a coach and consultant, I'm learning that the kindest thing you can do for your clients is to let them figure things out for themselves. That's the best way to learn. It's the only way I've seen lasting change happen. When we step in and steer the boat for them, they tend to take their hands off the wheel and leave the driving to you.


Potty training didn't go exactly as planned

But it can be tough - like leaving a child crying because he needs to learn to go potty by himself. Sometimes it takes real resolve to stop yourself from stepping in.

And, yes, that does mean that - in the beginning - there will be palavas and tempers and tantrums, and sometimes you'll end up with poo on the floor.

But if you can get over that difficult stage of breaking the dependency, you'll more likely as not be rewarded with a client that has really taken the lessons on board and who takes responsibility for solving their own problems more readily.

Lest you wind up just being the "build guy" or the "Hibernate guy", which means the moment you walk out the door, there'll be poo on the floor again.

My "Simple" 30-Minute Project Was Delivered 10 Minutes Late

 

Believe it or not, when I recorded the TDD screen capture posted yesterday - which was a couple of weeks ago now - I actually did a dry run and a couple of takes before the final version.

Each time I wrote exactly the same code. I mean exactly the same.

The dry run took about 45 minutes.

The first take had to be aborted after 15 because my IDE just wouldn't "play the game" in the middle of the refactoring, and I got into a bit of a pickle and said a rude word.

The second take fouled up within 5 minutes when Visual Studio locked up while running a single unit test and I had to CTRL+ALT+DELETE my way the hell out of Dodge.

Even in the third take, my lousy typing and some dev environment foibles made it less than plain sailing. It took just under 30 minutes to complete.

I did another full take after that one - which took 40 minutes for some reason. Again, exactly the same code.

So you see, even for just four unit tests, writing precisely the same code, there's considerable variance in how long it might take. Even a 30-minute project duplicating code I've already written four times can come in 10 minutes - that's 33% - late...

Test-driven Development Illustrated for .NET

 

I always find it hard to effectively communicate what TDD actually is. I think you have to see it, and then do it, to really get your head around the practice.

So I've finally gotten around to posting a dynamic worked example so you can see the process I go through, and see the kind of end result you might get.

It's a very simple example, with just a handful of tests, but hopefully it illustrates TDD in a way words seem unable to.

The video's about 30 minutes long and you'll need an up-to-date version of Macromedia Flash. Click here to view it.

It was created using Camtasia Sudio, which I thoroughly recommend for this sort of knowledge sharing.

Blog's 3rd Birthday

 

An anniversary I missed was this blog's 3rd birthday on April 10th.



A big thank you to all my loyal readers. All 9 of you.

Cheers!

Father & Daughter Discover Weather Reports Little Better Than Chance

 

Those of us who are fascinated by our propensity to delude ourselves that we can predict or control complex phenomena like stock markets and software projects might find this post on the Freakonomics site amusing.


There'll be scattered weather throughout the region, so don't forget to wear some - er - clothes

A chap called Eggleston and his 9-year-old daughter monitored the weather reports of 6 news channels for several months, and compared their predictions with the actual weather outside.

Guess what they found? Well, you probably already know how it turned out...