I Really Don’t Know

Well who then?

Ok/Cancel has a great comic this week that I feel points at something more fundamental.

Who “owns” the design. The design, in this posting, being what the application must do and how it should do it. Now, many would say that requirements are written by Analysts, and I would agree, but requirements aren’t a design.

Often the Technical Lead feels she owns it, but surely that’s the technical design? Maybe the Interaction Designer? Well, I’m sure Tom Chi would be the first to say that they can only design what’s been decided on.

At Microsoft it falls to the Program Manager (note the spelling, Program, not Programme) and that makes sense in many ways but most organisations don’t have anyone with that title.

At Apple it’s simple; it’s Steve Jobs.

So where does/should it sit? Being able to boil down the essence of a problem or opportunity that many people have and present a solution that meets that need is an unusual gift.

Security in Redundancy

I’ve just been catching up on Bruce Schneier’s blog and this article on Security following hurricane Katrina made me think about some stuff.

Firstly, he’s spot on about security spending. I hope we have time in the UK to change our tack and spend the 3 billion+ planned on ID cards on something more worthwhile.

But what interested me more was this:

Redundancy, and to a lesser extent, inefficiency, are good for security. Efficiency is brittle. Redundancy results in less-brittle systems, and provides defense in depth.

This is where the approach of re-using code and removing duplication really hurts and where the Agile community really needs to re-think things.

The strive to reduce duplication has clearly had a negative effect on software. Software today throws up more bugs and error conditions than at any other time in history and this can be attributed to the removal of duplication.

Removing duplication, as any sysadmin will tell you, reduces your availability. The same principle applies to code. The fewer routes there are through the code and the fewer implementations you have of your business logic the higher the percentage of your transactions will end up going through those inevitable bugs.

Ever wonder why so few banking transactions fail today? The answer’s simple. The massive duplication provides substantial redundancy throughout the code, allowing a high proportion of those transactions to pass cleanly through areas where the bugs aren’t relevant to them, only occasionally getting that fatal combination of a particular type of data and a particular bug.

If this duplication was removed through the ruthless re-factoring that the XP community advocates, a far higher number of transactions would pass through that inevitable bug.

;-)

Duplication, Code Re-Use and Effort.

For a long time I believed what most people in the industry seem to believe - that code re-use is a good thing.

I’m not sure that’s the right message any more. Of course I still believe that code re-use is a good thing to aim for, but…

› Continue reading

Aardvark, BDUF and Getting your story straight

I’ve got a huge amount of time for Joel. His attitude to businesss, developers, workspace and more are great, but sometimes he writes something that makes me cringe.

Yesterday, he published the spec for Copilot, codenamed project Aardvark, for the world to see. For that I’m truly greatful - it’s always good to see what others are doing.

But in the surrounding blurb, he says:

As I worked through the screens that would be needed to allow either party to initiate the process, I realized that Aardvark would be just as useful, and radically simpler, if the helper was required to start the whole process. Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that.

What XP “fanatics” say is that you don’t need to do BDUF on how you build the thing. What Joel’s talking about is BDUF on _what_ you build. Many XPers call this “getting your story straight”.

Rachel Davies has spoken about this with respect to stories having a cost element. Fuller document is on BCS’ wiki.

Olivier Lafontan talks about this in his excellent post where he discusses eXtreme Analysis and the NoVNoS Framework

And back at XPDay3, David Leigh Fellows and Richard Watt presented on Acceptance Test Driven Development, giving a clear view on how “getting your story straight” preceedes estimates and planning.

Anyway, here’s Joel’s useful post with the spec in…

Updated: Anthony Williams has picked up on the same point. Anthony sites “design at the last responsible moment” as his headline and that’s a great mantra also. The term missing from Anthony’s post, though, is Interaction Design.

This, in my mind, is the biggest hurdle. Joel is talking about refining the Interaction Design of his application. I have long said that this is the major difference between a traditional requirement and a story. A story is a fragment of interaction design; the XP process is predicated on the story being written by someone who knows what that interaction should be, but alos on allowing them to change their mind.

Standing on the Shoulders of Giants.

Building on the successes of larger complimentary and competitive organisations has to be a sound strategy. Leveraging other people?s investment to make money yourself has to be a good move. This is so often referred to as Standing on the Shoulders of Giants.

But what?s the best way to do that with software? The mental image of a normal person like you or I standing, one foot on each shoulder of some gargantuan Neanderthal, is evocative and illustrative, but can be interpreted too literally.

One giant good. Two giants better.

So, if standing on one giant is a good idea, surely standing on two is better. Yes and no. If the two giants choose different directions there will be very precarious moment as you teeter back and forth trying to work out which giant to stand on and which to step off. Sometimes, if you fail to move quickly enough, this can result in a long fall to the ground in the gap left between the giants.

You may also find that your initial position of only one foot on this giant still leaves you with a difficult move to reposition with one foot on each shoulder. And, of course, you may find that the other shoulder isn?t free, instead occupied by a competitor, standing one foot on your giant and one foot on another.

Standing on the shoulders of giants also limits you to the number of giants you can stand on ? for most of us the practical limit is just two.

Giant Headwear

If I were a giant, standing in the commercial world, I?d probably encourage smaller players to stand on me. That way if another giant comes along with a big club and clobbers me I?ll be protected. In fact, several smaller players perched upon my sturdy shoulders would make a very effective helmet. And, if one of them suffers I?ll be able to protect myself as long as I can keep getting new club-fodder to climb on up there.

Standing alongside giants.

Perhaps a better approach would be to stand behind Giants. Or alongside them in a position that leaves you free to dive for cover behind those mighty legs. Thinking about it, I can stand behind many giants. I can run between them, standing alongside each giant as and when necessary. There?s a risk, of course, that I might get trampled. I?ll have to keep my eyes open for giant feet, but with any luck they?ll be a giant to stand alongside whenever I feel vulnerable.

What?

So, what am I getting at? Well, standing on the shoulders of giants is a sane and worthy vision. But it is all too easy to translate it directly into software architecture. Take database integration as an example; tying product to a single database limits your customer base to those who find that choice acceptable. Working with many protects you from that concern. Of course, if you?re a giant you don?t have to worry too much.

The equivalent of standing alongside giants is to build platform independent systems, running on Windows and Unix. Write BizTalk or Sharepoint components to allow customers of those products to work seamlessly with yours ? but build the same things for BEA Process Portal and IBM?s WebSphere Business Integration Server too.

If you can only afford to stand next to one giant that?s fine, but don?t stand on his shoulders.

The promises (and arrogance) of youth

I’m working on a product team building the next generation of a very large metadata storage solution core to library systems. I’ve been about 6 weeks now and have spent a good chunk of that time looking at the standards and protocols that are in use in the environment.

The first is “a computer protocol that can be implemented on any platform, defines a standard way for two computers to communicate for the purpose of information retrieval” - the ANSI/NISO standard for Z39.50. The interesting thing, having been working with web services since 1999, is that this standard was ratified in 1988 and by 1992 had a second ratified version. Even more interesting is that it is both more efficient than SOAP and delivers on 90% of the promises made by SOAP, which is probably more than SOAP does.

The second “defines a data format that emerged from a Library of Congress-led initiative that began thirty years ago. It provides the mechanism by which computers exchange, use, and interpret bibliographic information, and its data elements make up the foundation of most library catalogs used today”. This is MARC, MAchine-Readable Cataloging, and delivers a structured format general enough to exchange any data. The first definition of this standard was made by the Library of Congress in 19… 66.

Both of these standards (and you pass MARC records over Z39.50 if you want to know the relationship) were formed at a time when many of us were, in the case of MARC, not born and in the case of Z39.50 still at school.

Now, everything goes in cycles, but this is quite amusing. These are great standards that deliver on inter-platform and inter-vendor interoperability and have been established and underpinning our libraries for decades.

Wow, it’s way too easy to think our thoughts are new.

Use Cases and iPod

Talking with some friends a few days ago we were talking about the value of use cases, amongst other things.

My product team are in the process of identifying user classes, looking at defining personas for them and getting really clear on the use cases required.

A colleague of mine, Ian Corns, is an excellent analyst, new to the analysis game and gaining a head of steam very quickly. He’s been reading Wiegers book on software requirements which appears (not having read it) to be very sound.

But I’m keen to avoid one of the main thrusts of processes like RUP and the Rational approach and also espoused by a new found friend of ours, Ian Alexander - Traceability. And that’s what we were talking about.

My previous employer, a services company, had a chief architect who designed an enormously contrived UML “world” solely on the basis that requirements should be traceable through to lines of code. Woah, what an idea. Maybe, in some world that I’m not living in that may be true, but I think it misses the point.

Product companies dream of having a product as successful as the iPod, people have talked for a long time about the apple factor and apple appeal. So the question is: Will you get an iPod if your focus is on Use Cases and traceability?

I don’t believe you will, I think you’ll get something very different. By isolating each use case and focusing on the traceability you establish the criteria that is being measured. And if you don’t measure what you value you end up valuing what you measure.

To make traceability measurable, use cases and their realizations start to form a one-to-one mapping. “I’ve done that use case, see here’s the screen” whether at the design or build stage.

But the iPod clearly doesn’t do that. The iPod has a set of capabilities - a wheel and a centre button that drive a very adaptive menu. The behaviour of the iPod changes depending on where in the iPod you are. Can you imagine the many-to-many mapping diagram for the use cases of an iPod and the components within it? It may not even be measurable.

My Creative Zen 60Gb player is a different story. You can map the use cases of that almost one-to-one with the physical controls. It’s horrible. I’ve hated it since the day I bought it (buy an iPod instead). The sound quality is awesome; it plays WMAs (of which I have many) and it’s only a little larger than an iPod. But it’s horrible: it takes two hands to use; operations often take several trips through the menu to achieve and it’s ugly.

How do Use Cases and traceability allow me to define a product that users will love, not just one that meets the use cases?

The answer, of course, is Interaction Design. As Alan Cooper so beautifully puts it in The Inmates are Running the Asylum, the whole industry is crap and interaction designers are the only people who can save us.

And I think that’s so true. Almost. Well, maybe, if you’ve had a beer or two.

But the point he raises is very real. So many of us work in environments where a requirements document is handed to a developer to work from. In some cases an architect may have pinned some technical constraints or ramblings to it, but broadly speaking there is little or no Interaction or UI design.

So, why do we get crap instead of an iPod? Rhetorical Question.

A fool with a tool is still a fool

Further to my recent posting on Kit I found myself amused by an advert running here in the UK from Barclays called Money Trees III. The advert, features Donald Sutherland and Gary Oldman talking about growing money trees and is a fabulous outline of any skilled work…

What amused me was the way Donald Sutherland switches tack at the end and reminds me so much of the meetings everyone has great anecdotes about… You know, the ones where you try to explain why you need the re-factoring tool and the book.

Kit

The Effect of Sound Tools for Developers

When we want to develop sound software, you know the stuff when you see it, great interface, fast response, really solid, the importance of tooling people up correctly is beyond measure. We (Developers) all know that, but often development organisations find it difficult to argue the point and justify the tools they need.

Consider this (they’re all real)…

› Continue reading

TDD, Liskov Substitution Principle and Open/Closed Principle

In my current role I’ve been working on a number of framework style components that allow developers to focus on the specifics of the task in hand and, hopefully, ignore the generic and common plumbing and orchestration. One of the frameworks is a reporting framework, the other an exception handling framework. One of the things we’ve been trying to avoid is inheritance where other methods would be better, but type compatibility and inheritance of some functionality appears to be the best model for some of what we’re doing at least. Which raised a big debate about Fragile Base Class problems*. Of course, one of the guys piped up with the Open/Closed Principle, but was trumped by a reference to Liskov’s Substitution Principle and so the talking shop went on…

› Continue reading