Agile Software Process Improvement

The World Has Finally Gone Mad

 

And here's the proof...

Apparantly an 8-year-old boy has been reported to the government by his school in Sweden for violating the human rights of two of his classmates.

His crime? He didn't invite them to his birthday party.

Self-Directed Learning & A New Direction for Little Old Me

 

This is going to sound like a very damning confession from someone who earns his living teaching and coaching software developers, architects, analysts, managers and the like.

My own experience on the receiving end of the services I offer is that - while I'm quite capable of learning - I cannot be taught.

When I look back, I see a long history of my taking an interest in something, going out and buying a book or three about it, and figuring it out off my own back.

Being locked in a room for 5 days with some trainer with a data projector and a set of PowerPoint slides just never figured in my own professional development. Sure, I went on courses. But I look back and I have to honestly admit that I would have done just as well to read the book and try stuff out in my own time and at my own pace.

And that's my latest epiphany about what I do. Just as I finally realised that an architect can't really make all the design decisions for the developers, a teacher or coach cannot learn on your behalf. They can lead the horse to water, but they can't make you drink.

So if I'm sat in a room full of experienced developers and I'm supposed to be teaching them, say, Test-driven Development, or OO design, or UML, or whatever, the first question that pops into my head is "why don't they already know this stuff?"

If they really wanted to learn, than - at some point during their lengthy professonal careers - they would surely have picked up a book about it? The fact that they didn't sends a very clearly message. They don't really want to learn this stuff.

Which might explain why so many courses I've delivered, and so many coaching assignments I've done, have essentially been taken up largely by efforts to persuade people that this stuff actually has value and that they really should want to take the time to master it.

And that niggling little voice has been gnawing away at the back of my mind for years now. People - especially grown-ups - learn because they are receptive. The very fact that they have hired me to come in and try and bash it into them suggests that they were never all that up-for-it in the first place. And oftentimes, I'd just be wasting my time.

They're smart people, of course. They'll apply themselves and get through the training or coaching. But a few days or a few weeks with me sitting next to them saying "shouldn't we write a test for that first?" and "do you think we should draw a picture of this before we try to code it?" barely scratches the surface of their ingrained values and habits. The people who really learn and who eventually master these techniques do it the way I did - off their own backs through months and years of self-study and practice. They may have collaborated and helped each other out (as good students often do), but ultimately a lot of it was entirely self-directed - like anybody who gets really good at something.

My recent experience with BBC Worldwide has been one of the most satisfying professional experiences I've had in my career. And I put a lot of that down to the fact that I approached it with total realism for the frst time. Anything I genuinely believed wouldn't work, I didn't do. In particular, I didn't kid myself that I was teaching them to be better software developers. That has always been a great conceit on my part - and on the part of everyone who dares to believe that they can teach intelligent, educated, independently-minded adults.

Instead, I finally admited that my real job is to persuade people that they want to learn. And not in any bulls**t manipulative way. I've focused the largest part of my effort on being a catalyst to help recharge people's interest and passion for what they're doing.

And it was always there in each and every individual working in the IT department - even (gasp!) the project managers. Scratch the surface to see beneath the years of rough-and-tumble that jades all of us if we stay in any job long enough, and you'll see that even the most jaded of us really does care.

I haven't taught the folk at BBC Worldwide a single useful thing. They taught themselves, and continue to do a great job of that. If they're special, it's only because the BBC culture stills dares to cultivate passion and genuine curiosity and open dialogue, while many corporate environments try to stamp it out.

But I'll bet you this: every person in your IT team probably cares just as much as the folks at BBC Worldwide. Given the encouragement and support they need, they would be every bit as capable of the kind of transformation these folks are driving from the bottom up. It's all there - all that potential - bubbling just below the surface.

It takes a lot of courage to stand back and just let it happen. The managers at BBC Worldwide have allowed me to pursue a fairly radical way of catalysing change. And even when it really p**sed them off, they acknowledged the results and let me continue. Cultural change is the hardest of all, but it gets the best, longest-lasting results. I take my hat off to the boss who allows anyone to come in and start rocking that boat!

The experience for me has been transforming, too. I'm not the same consultant I was a year ago. And my career goals have changed as a result of this experiment. I now know that encouraging people to care and to take responsibility for learning and sharing knowledge as I have done, and the folks at BBC Worldwide are doing now, is the be-all-and-end-all for me.

"Don't You Know Who I Am?"

 

This blog post is hilarious on just so many levels.

The guy had an interview with Microsoft. They were nice to him. They offered him a job. Microsoft, he concludes, are great.

Google also interviewed him. They did not roll out the red carpet for him. Google suck.

I was especially amused by his glowing report of Microsoft's "nearly perfect" development processes...

miniSPA 2008

 

Blah blah blah.

It's summer again, and that can only mean one thing: it's almost time for another miniSPA conference in London's glittering tramp-infested Covent Garden.

I like miniSPA. It's short. And I like short conferences. It's also punchy. You just get the highlights. And I like punchy highlights almost as much as I like short conferences.

If you like software practices to advance, and are a fan of short, punchy highlight-dominated conferences then - by it's very definition - miniSPA is the one for you.

They do nice cakes, too, as this ]old report proves with irrefutable photographic evidence.



It's also free. Which is nice.

You'd have to be a total nutjob not to go.

(And no, as it happens I'm not going. And yes, I am a total nutjob. QED.)

Pro-Waterfall Rant Highlights Nature Of The Delusion

 

Check out Linda Wilkinson's blog post in which she quite rightly assumes that I am young, inexperienced and misinformed about matters pertaining to software methodology.

Linda cogently argues:

So let's talk about waterfall. The Real Deal, not the assumptions made by people who don't remember dumb terminals and have never worked on a project that "admitted" to using waterfall technique.

I've never, in more than 25 years, EVER worked on a waterfall project of any size whatsoever that wasn't broken down into workable pieces or that was moved into production in one big "bang". In addition, do you realize the quality of software products over the past 20 years has gone down, not up? Do you think that indicates your predecessors were stupid or that we do things "better" now?

No. Back in the "olden days", breaking a large project into smaller, workable pieces was called "phased delivery".

And there you have it, folks. That's the only freakin' difference. "Phased" vs "incremental".

Terminology.

You're indulging in a myth if you think users were not involved early and often in the process. You're indulging in a myth if you think there was some kind of gigantic, all-encompassing design document at the get-go.

And that, my dear Watson, is why those "poor deluded people" believe the way they do. Poor "crazy folks".

So, as you can see, I stand corrected. "Waterfall" development is actually iterative and incremental and involves users throughout the development lifecycle.

Remember, you heard it here first, folks!

Anyway, sarcasm aside, maybe what Linda needs is a little history lesson about the origin of the term "waterfall model". Of course, having literally just this minute hatched from the breeding facility they grow contextualists like me in, I was not there at the time and can only relate that which I've managed to glean from books and wotnot.

The term was coined after an article published in 1970 by Winston W. Royce, to describe development flowing steadily downward through phases of requirements analysis, design, construction, testing, integration and maintenance. Ironically, Royce presented this as an example of a flawed, dysfunctional model for software development. Despite this, Royce's criticisms of the model were largely ignored, and it was actually adopted by many organisations as "the way to deliver software".

Not so, said Royce. He went on to propose an iterative sequence of "waterfalls", the closest equivalent model today being widely known as the spiral model. What Linda describes is NOT waterfall software development. Waterfall is what Royce argued against in his article. Spiral is what he advocated. And that, by the sounds of it, is what Linda has been successfully doing all these years.

But she believes she has been practicing waterfall development. Which, technically, is a delusion.

Back To Work

 

First of all, the astute among you will have noticed that I've failed to deliver on my promise to update the pledges on icareaboutsoftware.org and to have designed a logo for t-shirts and wotnot.

As they say: the best laid plans of mice and men...

I took a week off to catch up on a whole bunch of stuff, but a week just wasn't anywhere near long enough, so I made a deliberate decision to put some of that stuff back another month or two. I will, however, try hard to be up-to-date by the end of the summer, as I suspect in the autumn my circumstances will have changed again, with a new challenge and a new commute to contend with. Being a freelancer, the road ahead is always dark and unknowable like that.

Certainly, I'm back in the harness at my client site and seeing things have been ticking along just dandy without my saintly presence, which is usually my queue to move on.

I've used the analogy before about air conditioning that blows warm air into a hot room, but I am starting to feel like I might be reaching equilibrium with my surroundings. When that happens there are two courses of action:

1. Go to another environment where I'll be at a different temperature to them again
2. Choose to stay and "go native"

99% of the time I would rather eat my own arse than accept a permanent position. In this case, however, I'm surprised to admit that I might actually seriously consider it, such is my fondness for this particular client and the strength of belief in what we're doing.

Alas, I suspect no such offer is going to be forthcoming (remember, I've been blowing freezing cold air at them for several months, which tends not to enamour senior managers to me even when it gets the desired results) and so I will be keeping my ear to the ground for interesting new projects.

In the meantime, there are a couple of interesting innovations going on here that I hope to share with you before the summer's over. Those, as well as the I Care About Software thingummyjig, look likely to become very prominent in my future work.

Catching Up With icareaboutsoftware.org

 

I'm currently enjoying a holiday at home.

Living in London, there are good points to this and there are bad points. The good point is that the amenities are pretty much unbeatable. Shops, bars, restaurants, cinemas, bowling alleys, parks, gyms, swimming pools, golf courses. You name it, London's got it in spades.

So I'll want for nothing while I'm enjoying this break.

The downside is that my mind is still at work. Indeed, technically, I am still working. I've got a bunch of stuff I have to catch up on, and I'm slowly chomping my through it all.

The difference is, I'm doing it outside a local bar with a nice cool drink. And I didn't get started until I'd had a relaxed breakfast listening to BBC Radio 4 (instead of starting my day with 75 minutes on the Underground.)

So I am working. But without the commute, and because I can focus on 'my work' as opposed to my client's needs, it feels like a holiday. And I'm enjoying catching up with these things.

One of the things I'm catching up with is the whole I Care About Software thing. 3 hours of commuting every day takes its toll, and one of the things I've let slide is updating this web site. People have been emailing me their pledges, but I just haven't gotten around to posting them on the site.

And I think the numbers are now well past the 100 milestone that I suggested would trigger me to escalate the whole thing. Right now, I should be actively pursuing the target of 1000 pledges that I proposed this time last year. I recall I also said something about designing a logo and artwork to release under a Creative Commons license so that folk who want to can get t-shirts and badges and posters and wotnot printed to declare themselves to the world and help spread this vital meme.

So my promise to you now is that, by the end of this week(end), I will have all the outstanding pledges posted on the site. I will also have a logo in appropriate file formats, and I'll order myself some t-shirts and badges so I can 'be the change I want to see in the world' (as Gandhi puts it) and hopefully spur others on to do something of their own.

So watch this space. And please pledge if you haven't already.

Challenging The Waterfall Delusion

 

It's fashionable these days for folk in the software industry to poo-poo attempts to establish standards of quality or professionalism, because - in their own words - "there's not one thing that we all agree on".

I've tried to think of something. Something that no sane, rational person could argue against.

Iterative and incremental development springs to mind. Surely there's nobody left out there who can cast doubt on the idea that it's less risky to deliver a little slice at a time, and to incorporate feedback after every increment? Surely plan-driven, Big Design Up-Front, "waterfall" software development is now so discredited that we can - once and for all - remove it permanently from the software professional's toolbox?

It's undeniably true that an iterative and incremental approach is less risky. There's a very simple statistical reason why it's better to solve complex problems in this way, which is why nature has selected it as the de facto "search engine" for finding all manner of solutions. And decades of project data provide strong evidence that the statistical argument is true.

So why can't we all now accept iterative and incremental development as the more viable approach in pretty much every situation?

The problem isn't that the argument hasn't been won. It has. Years ago.

The problem is that not everybody is prepared to be sane and rational about it. Just as some religious fundamentalists cling on to their nonsensical creation myths, in spite of the overwhelming evidence that life, the Universe and everything didn't start that way, we still have our own religious nuts who choose to ignore both the inescapable logic of the anti-BDUF argument and to ignore the mountain of evidence that supports it.

These days, we're so politically correct that we prefer to humour these poor, deluded people and make the grand mistake of allowing their ideas to persist unchallenged. And that's why waterfall stays on the table: to spare the feelings of the crazy folk who still believe in it.

In the long run, we're not doing them any favours by being inclusive to this extreme. It's much kinder to confront them bluntly with the reality: there is never a situation where it is less risky to work with less feedback less often. Indeed,l I believe that waterfall itself is a myth and that it's actually impossible to deliver anything useful without iterating - even if you leave it until the "acceptance testing" phase (or the "stabilisation" phase, or whatever you want to call that stage in the project where the user feedback starts gushing in and you're forced to make a rapid series of smaller releases, incorporating user feedback, to fix the problems and make the software for purpose.)

Dynamic Languages, Substitutability & Unreused Abstractions

 

Just a quick note today about dependencies and change propagation.

I've talked before - in typically ill-considered and handwavy terms - about the need to unify principles of software and system design across the various levels of organisational granularity:

* Code statements in methods
* Methods in classes
* Classes in packages
* Packages in applications
* Applications in service-oriented and/or enterprise architectures
Etc

At each level, units of code are organised inside higher-level units of code. And as much as possible, we want the effect of changes to be localised inside the units of code in which they start.

There are, to my mind, three ways in which we can minimise the 'ripple effect' of change propagation. Since change propagates along dependencies, then we can:

1.Have fewer dependencies - if we write less code, then that'll mean less dependencies, too
2.Encapsulate dependencies - for the code we had to write, wherever possible we should see to package dependent items together inside the same higher-level units of code
3.Depend on things that are less likely to change - for the dependencies we can't encapsulate, we must seek to have them go towards units of code that are less likely to end up changing

The third strategy has been traditionally talked about in terms of depending on abstractions (e.g., 'program to interfaces'). But it is not abstractness that is necessarily the deciding factor here.

The real question should be: how easy would it be to replace X without anything that depends on X being effected? And the quality we're looking for here is not abstractness, it's substitutability. In dynamically typed languages like Ruby and SmallTalk, everything is substitutable, which may go some way to explaining why some programmers favour the freedom those languages give them.

In statically-typed languages, like C#, things often have to be declared abstract or virtual to allow us to subtype them (e.g., methods in C# can't be overridden unless they are declared such that they can be). The tendency of developers who follow the 'program to interfaces' mantra to declare interfaces for pretty much everything could be argued to be an attempt to make up for this shortfall in inherent substitutability.

Certainly, in my own experience, these interfaces-for-the-sake-of-interfaces clutter up projects and make code more complex and harder to maintain. I added a complementary OO design principle called Reused Abstractions to try to counter this - sometimes very damaging - tendency.

Surely we could find a way to provide the high level of substitutability we need without resorting to redundant abstractions cluttering up our code?

Mobile Computing Finally Arrives At Casa Gorman

 

Isn't modern technology wonderful? I'm sitting on my little balcony typing these words into a brand new Asus Eee PC that I bought at the weekend.

Gadgets are usually a bit of a let-down, don't you find? The marketing hype makes it sound like the cure for all ills, but when you get it out of the box, it turns out to be just another flakey pile of over-promising, under-achieving plastic crap.

But not my new Asus. I'd heard from several people who've got one how good they are, and so I figured I'd take the plunge.

My first observation is that it's a more powerful computer than the laptop I bought in 2001. But then, so is my mobile phone.

What really sets the Asus apart is that you can use it pretty much like a laptop, which could never be said of my phone. It has almost identical applications. But I could never really get the hang of mobile computing using my handset. It's just too fiddly.

The 7-inch Asus is just on the right side of laptop-sized to make typing things like lengthy blog posts, as well as web surfing and watching videos, so much easier and more fulfilling.

But, unlike my laptop, I can take the Asus just about anywhere. It's also so cheap that I don't feel anywhere near as paranoid about it being broken or stolen or getting lost in the luggage at Heathrow Terminal 5.

And you can do stuff using an Asus that goes way beyond what the hype suggests. For example, nobody told me the VGA output allowed display resolutions up to 1024x768. That's fantastic for people like me who spend half their lives dragging laptops around to show PowerPoint slides.

The media player will happily chug through 480p video files, which is the native resolution of the screen. And, thanks to 3 USB 2.0 sockets, you can attach DVD players, external hard drives of any size and – my favourite – HSDPA mobile broadband wotsimafloojits. My Vodafone 3.5G modem worked first time. Happy happy joy joy.

So as soon as I'm fit for duty, it's off to the beach with my new toy - I mean, serious work tool...