The USS Quad Damage

Nowadays, software has so many options,
and the things you want to do are so
diverse, that having a menu system is far too
complex. Microsoft Word already has an
annoying little icon when you paste something
(paste as text, paste with destination style, or
paste with source styles). The addition of the frankly backwards looking ribbon also shows the flaws of interactivity through menus.

I think that as the industry moves towards
agile programming, user scenarios to stories, and other
forms of requirements drawn around what the
user is trying to do, it begins to make
sense to start representing the UI as a conversation
between the programmer and the user. This convention is starting to become more prevalent in web design already. The home page on a website will often list a number of tasks you might want to accomplish. You simply click the link to start accomplishing the task.

In this worldview, you have a series of small
steps which are common to a variety of “flows”,
and “flows” which link into one another like
mobile phone word suggestions. The flow idea may
seem constrictive, but even when starting an application,
for example, there’s only a small number of tasks
you can do anyway. After that, it’s just context sensitivity
which guides the user through what they want to
do next.

An example flow might be uploading photos to flickr,
which involves selecting the photos, labelling & tagging them,
adding them to sets, etc. Following that, you might want
to administer groups, add photos to them, etc. The nice thing
about doing this on a website is that both flows & the
way they are linked can be improved via crowd sourcing.

Agile software development is soon to be the next Capitalism: Someone is going to write a quote about it being pretty terrible, but still being better than waterfall. Eventually, there’ll be a worldwide crisis and we’ll all start talking about a “requirements revolution” where we pre-define the software we’re making. Well… maybe.

We’re starting to use Agile at our company. That’s with a capital “A”, not that it really matters. We’re a fairly pragmatic team, and we have a fairly good understanding of the principles. We’ve made a couple of changes, but they’re very minor. We intend to change things as we see it, so we’re fairly pragmatic (which means we’re willing to change our “A” to a little “a”, but we’d like to try the “A” first, just to see how it all pans out). Well… I suppose I can’t speak for everyone, but me at least, and I’m pretty sure it carries.

There are some problems. Actually, there are a fair few problems. The first is iteration 0: the bootstrapping which happens before the project gets going. Theoretically, this is all that’s required to get the developers all they need for the project. However, even at the very beginning of the project, we’re already in a second iteration 0. Maybe we screwed up the first one, but maybe there needs to be more time to develop things which customers need. This is the least of the problems.

A massive problem we’ve encountered is the planning phase of the iteration. This is supposed to take a day, at most. However, it’s been taking a lot longer than that. Even if stories are written correctly (not an easy task as I’ll explain later), creating the task breakown, especially to a state when each task is under a day, is a long and… eventful process. That’s if everything is fine and we don’t feel the need to split up a user story.

User stories and scenarios have issues of their own, and this is what I perceive to be the biggest problem with agile software development. Because these things are vertical slices, not only are these stories difficult to split up, but you can instantly tell agile software apart from regular software. In agile software, you can do complete your tasks really quickly, but if you want to complete a task for which there’s been no user story, all of a sudden it’s not possible due to the way the software has been designed.

Refactoring is a fear, but not a realisation just yet…