[various examples and illustrations of bad usability]

What does usability include in web apps?

• Learnability
• Efficiency
• Memorability – how easy is it to pick up an application again after a few months’ absence
• Handling errors
• User satisfaction

How much should you focus on each of these? As usual in software development, the answer is “It depends”.

• How many users will the system have?
• How often will they use it?
• Will they get training?
• Do they have alternatives to using your application?

How do you find usability problems?

• Ask users
• Watch them
• Try doing it yourself
• Just as comments are a code smell, (the need for) documentation is a usability smell. Warning signs include post-its stuck to the screen, looking things up in the manual.

Paper prototyping is a powerful tool for evaluating usability. Test them with actual users!

My opinion: A good intro for those who have never given usability much thought. Luckily we’ve come a bit further than this with our application.

The Agile Manifesto has an outward focus: it tells the business how the development team will work with it. What it does not talk about is how the team must work within itself and with the code.

What should the team keep in mind?

• Joy
• Naivete: ignore the people and books who say that it’s impossible
• Ease: tools should work as if they are a natural extension of your hand. Pay attention to what it feels like to work. Spend time fixing the annoyances.
• Reactive: ignore the future. Don’t back up – change your course forward instead. This forces you to make your code easy to change.

Being wrong: is an opportunity to learn.

My opinion: Nice words and nice thoughts, but what do I actually do with them? Less inspiring than Brian’s first talk at ScanDevConf; rather vague and fluffy.

Development should start with user stories.
Then break these down into acceptance criteria:

• Given «situation»
• when I «do this»
• then «this happens»

This should be done before the sprint planning meeting. Know what you commit to!

The rest of the session was a demonstration/walkthrough of automated BDD.

My opinion: The non-automated part of the session was a somewhat useful recap of BDD. The automated example involved, as usual, an extremely simple application and extremely simple user stories. While I understand that it will work in that case, I have great difficulty envisaging how we could possibly use it in our system.

What is a team? A group of people with…

1. a common purpose, undertood and committed
2. interdependent work and skills
3. a shared approach to this work
4. joint accountability
5. small size
6. a mutual history (at day one, you are not yet a team)

How do you achieve these? What do these imply?

1. A project kickoff, project charter; reminders and mini-re-kickoffs
2. Think about what skills are needed before you select people for your team
3. Have a working agreement – “we aspire to work this way”. Make implicit norms explicit.
5. If the team is too large, it will break into sub-teams.
6. Common adversities and successes; stories to tell about the team; knowing each other.

My opinion: Basic stuff. I guess there are groups out there that need these tips but they were not of much use to me.

A supershort summary of Scrum:

• Split your team into small parts
• Split your product into small parts
• Split your time into small parts

… i.e. instead of a large team working on a large product for a long time, you have small teams working on small pieces of the product for short periods of time.

Kanban is:

• a signalling system
• with visible indicators
• that are limited in number.

Kanban in software development includes:

• visualizing the workflow (with columns on a whiteboard)
• visualizing the stuff in workflow
• limiting work in progress (WIP)
• measuring and optimizing flow
• explicitly defining your policies – the definition of done, WIP limits etc

How do the two differ?

• Scrum has more rules than kanban. On a scale from prescriptive to adaptive, the order would be
  RUP > XP > Scrum > Kanban > do whatever works.
• Scrum defines roles while Kanban doesn’t. In practice they might look the same.
• Both are empirical and measure things (velocity, lead time, quality etc). Kanban gives you more knobs to twiddle to change the outcome.
• Scrum has one cycle: planning and committing, releasing, and retrospectives, all three are done on the same cycle. Kanban does not tie these together; you could have a different cycle for each one.
• In Scrum, items must fit within a sprint. Kanban allows long-running tasks, limited only by WIP limits.
• Both limit WIP. Scrum limits by velocity, per time; Kanban limits by column in the workflow.
• Scrum discourages mid-sprint change: “We want to work in peace and quiet for a few weeks”. In Kanban, you just need to wait for a slot to become available.
• In Scrum, the board is reset between sprints. In Kanban the board has a long life. Scrum gives you closure and a feeling of success, but also some waste.
• Scrum prescribes one team per board, cross-functional. Kanban is more permissive of specialist teams.
• Scrum prescribes estimation and calculating velocity. In Kanban both are optional.

For more information, read the free PDF minibook.

My opinion: Well-structured and informative. I’d been curious about Kanban, wondering if it might be worth trying instead of Scrum (which we use now). After this presentation I have a good grip on the differences between the two and know that Scrum suits our needs better.

The short answer is, You can’t.

Before discussing the differences between the old and the new, it’s useful to remember that the “old” way of work, command and control, has only existed for the past 80-100 years.

Now the old kind of work is being replaced by knowledge work, where the workers know more about their job than their manager does. The old kind of management no longer works.

Old management activities are: planning, organizing, budgeting, monitoring, directing, supervising, evaluating, controlling, commanding.

New management: managers focus on flow, people and value, and continuous improvement. Their job is to enable and facilitate.

New management activities include mentoring, mediating, protecting, advocating, acquiring and allocating resources, tracking and reporting metrics, supplying a good work climate, supporting learning, improving systems.

The people working are affected by the system they work in, and that is the reponsibility of management. Behaviour is a function of person and environment.

My opinion: This all seemed pretty self-evident to me.

This session was a live play showing pair programming in action – done right, and done wrong.

My opinion: Fun and relatively well done, but pretty basic stuff. The only thing it gave me was a reminder of the different roles that the two people in a pair should have. One to focus on the small, immediate stuff; the other to focus on the bigger picture – Are we doing the right thing? Are we doing it right? Could we do something else?

A core design pattern: intentional interfaces. Whenever you find yourself facing a design problem, tell yourself – “Make roles explicit”.

For example, a Customer class may be used to validate a customer before persisting it, for making customers preferred, and for adding orders to the customer. Making these roles explicit, the Customer class would implement IValidator, IMakeCustomersPreferred, and IAddOrders. Now that these are in place, we may use them, for example, to implement different fetching strategies for #2 and #3 – lazy vs eager.

Another example: there might be a CustomerService class for those same three tasks. Separating out the three responsibilities, the class might implement IMessageHandler, IMessageHandler and IMessageHandler. Now that this is explicit, we may split this into three different classes, which would (among other things) allow us to have several handlers for a single message, in a pipeline.

As a rule of thumb, define your interfaces starting from use cases. These tend to be a stable foundation to build on.

Often we think one interface – many implementations. With this pattern it’s the opposite: one implementation, many interfaces.

My opinion: This session is difficult to summarize without all the examples and step-by-step reasoning, so I’m afraid the blog post won’t do it justice. I found it useful, and the reminder to Make Rules Explicit will probably lead to better design with less sprawling classes in our code.

Note: In Agile development, a retrospective is a meeting at the end of an iteration (which a period of work, usually 2 to 4 weeks) where the team reviews the iteration together, and discusses possible improvements to their process.

A bad retrospective is: ad hoc, not prepared, with no structure.

The goals of a retrospective are two:

• participation
• decide on actions, what should we change (this is what new scrum masters often focus on)

Keys:

• Facilitation = planning, leading, setting a goal. Gives us flow.
• Framing = setting up and ending, making it focused
• Structure = ensures balance, gets everyone’s input

Facilitation

• Use an external facilitator. The person leading the meeting should not have an interest in its outcome. It is difficult to lead and participate at the same time. If not possible: be very clear about when you’re leading and when you’re participating.
• Work with the energy and the dynamics of the group. Take breaks; split into smaller groups when appropriate.
• Prepare. Think about what activities to use; when and where to have the meeting; is food needed, etc.

Framing

• Modify the retrospective according to its purpose
• Define the goal and agenda
• Not every retrospective needs to be about “how can we get better”
• Try retrospectives with specific themes: QA, communication, etc – gets you away from boredom and routine
• Start with a check-in: everyone says/draws something about the iteration
• Make it safe to participate

Structure
A retrospective should have three phases:

1. What happened? Why are we here? – In this phase we share context
2. Why did that happen? – In this phase we diverge, by brainstorming
3. what should we do? – In this phase we converge again, and decide on actions

Sharing context can include:

• Looking at raw data: burndown chart, story list, bug count chart
• Creating a timeline: write post-its with things that happened and stick them on the timeline (all at the same time or with individual preparation)
• An emotional timeline (a line chart scaled simply from – via 0 to +, and everyone draws their own line between these extremes)

During brainstorming, people write ideas and thoughts on post-its.

During the convergence phase, you can cluster the post-its, vote on them, discuss them in smaller groups, etc. At the end, the team commits to actions that are

• possible
• valuable/important
• someone who wants to do it

Finally, summarize: what have we learned, what are we taking with us.

My opinion: This was exactly what I needed. Chris’s comment about how inexperienced scrum masters always focus on “what should we change” really hit home. And our retrospectives have become relatively boring. This session gave me lots of useful, practical tips. I believe our next retrospective will be much better than the last one.

Why split user stories? A story may be too big to manage. Or different parts of it may have different value. Or some parts may be better understood than others. We’re looking for bargains: best value for least cost.

There are 4 categories of splits:

• high-level splits that get rid of lots of work
• “ilities” – non-functional splits
• UX splits – simplify the user experience
• behavioral splits – simplify behaviour

Technical splits are not recommended. Stories still need to make sense and be valuable to users.

High level splits include: research; partly manual process (instead of full automation); buying instead of building; deferring features.

“ilities” splits include: static data instead of dynamic (a “refresh” button instead of constant automatic refreshes); simplified persistence; lower fidelity; lower reliability; lower performance.

User experience simplifications include: batch processing instead of immediate response (generate reports off-line overnight); single user (instead of multi-user); API only (UI can wait); simplified UI style; a generic UI (textboxes in a grid instead of nicely aligned dropdown boxes etc).

Behavioural splits include: happy path first (ignore alternative flows and exception cases); fewer choices (0 or 1 instead of many, e.g. fonts in a text editor); base case first (wait with a more general solution); collect less data.

My opinion: Pretty basic stuff rather dully delivered. I could have just taken the one-page handout and not missed much.

There is a core in agile that is going missing now that Agile is going mainstream and crossing the chasm.

A problem with Agile is its name. Of course everybody wants to be agile. Look up the opposites in a dictionary: sluggish, torpid, immobile. Who wants to be sluggish and torpid?

So I came up with a description of Agile that is weird enough that nobody is going to immediately, before they’ve had time to really understand it, react with “oh yes, that’s me”: Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism.

1. Anarcho-syndicalism:
   • Worker self-management – no managers
   • Direct action. To take an example from the original anarcho-syndicalism, say you have a strike, and those opposing the strike are attacking you with clubs and guns. The standard approach would be to vote to elect a congressman who passes laws that prohibit violence against strikers. The AS approach is to get your own clubs and guns and protect your strikers. Don’t try to get into management to fix your problems, fix them now.
   • Worker solidarity: the team fails together and succeeds together, we’re all in this together
2. Team-scale: we’re not revolutionizing society, just helping your team
3. Artisanal: people on the team care deeply about the product and its users, sometimes more than the business. Counteracts the risk of becoming so infatuated with our process that we lose sight of our aim.
4. Retro-futurism: 1930s futurism pictured all sorts of nice things for the future, i.e. for now. Orbital cities, clean cheap urban transport, underwater cities, personal jetpacks. We didn’t really get much of any of that. The same happened with Agile. In the early days agile projects were few and far between, but everybody hoped that the idea would spread and make all developers happy. Instead we now have lots of teams doing Agile in name only. People on “agile” projects are saying “at least my job doesn’t suck as much as it used to” instead of “this is the best project I’ve ever worked on,” which is how it should be. Retro-futurism reminds people of the possibilities. Don’t accept things as unchangeable, change your circumstances to get where you want, keep that gosh-wow spirit.

To summarize the spirit of Agile:

• scrappy – we are trying to do something here, get out of my way
• care – for the product, the users, the process
• naive optimism

My opinion: Inspiring! Brian was an enthusiastic, passionate speaker who delivered a thought-provoking speech. New ways to think about old things. Conference sessions tend to fall into two categories: those where I learn new facts, and those that simply energize me and make me want to get back to work and improve everything. This is a prime example of the latter kind.

If you find this interesting, there is a bit more information at ARxTA.net, including a video of Brian delivering a similar talk some years ago at some other conference.

GTD and lean both aim to offload your mind. Instead of lots of wishes and worries, you have a defined list of things to do. At any point, you can just pick the next thing off the list.

Worry is waste.

We shouldn’t be breaking down requirements, we translate them into things to do.

My opinion: An interesting parallel to draw, but the presentation was confused and rambling. I do not know what he really wanted to achieve with this talk. And he spent way too much time talking about how great he is and what successes he has had. I had the same problem with his presentation at Agila Sverige 2009, but unfortunately I didn’t recognize his name until I saw him on stage. I will be avoiding this guy’s presentations in the future.

In the last 5 to 7 years there has been a lot of talk about process and not so much about design. When you raise the profile of one issue (process) all others tend to fall by the wayside. There’s also been a lot of focus on technologies. Developers in the .NET world discover things that were known in the Java world already 3 years ago, and vice versa. Design knowledge that was around has been getting lost in the generational shift. People think that they know design, but they don’t really. The design books people read tend to be 5 years old. Where are the new books?

There’s been a kind of a “design winter” – but we’re coming out of it now.

There is also a focus on things like TDD and emergent design. But these don’t mean that design is no longer needed – they require a tacit knowledge of design.

Trends worth looking at, regarding design:

• Software development is becoming more of an engineering discipline. We’re bumping into constraints.

  Hardware design has always been surrounded by constraints: heat, power. Software has mainly been constrained by our ability to make sense of it. No constraints means we do just about anything. We have capacity for unbounded complexity.

  Now software is beginning to run into hardware limits. Hardware is going to affect software; software will become more tightly coupled to hardware. Hardware will shape business. (Google was made possible by cheap hardware. Software that utilizes GPUs.) Hardware will lead to new business models that we haven’t even thought of yet.

• “It’s ergonomics all the way down.” User experience design used to be thought of as something off to one side, a separate discipline, a separate community with a separate nomenclature. But what we call “software design” is really “user experience design” where we are the users. That is one of the reasons why software design often sucks: we don’t take ourselves seriously as users.

  Design guidelines are all about ergonomics. Small classes and methods are easier to read. Cohesion and coupling have a cognitive basis.

Design will grow at the pressure points of hardware and user experience.
We’re entering an era with more constraints. Constraints will drive design. Design thrives in constraints.

My opinion: Not too impressed. I can relate to Michael’s point about the links between design and user experience. But software bumping into hardware constraints? In some parts of the industry I’m sure this is true, but I believe it’s something that affects a tiny minority of developers.

Most of the time my work fills that need. When I get home and Ingrid’s gone to bed, I’d rather blog, read a book, etc. My hobby programming projects languish untouched. I haven’t done any work on my Rails app for over a month.

But this week I have barely touched a line of code at work. Instead I’ve been installing a new build-cum-version control-cum-database server, migrating all of those things from the old server to the new one, plus getting our new developer up to speed, doing various administrative tasks, and handling customer support issues.

By Thursday I was definitely feeling the pangs of abstinence, and my Rails app finally got some attention again. Luckily it’s a small app so it isn’t too hard to pick it up again. The hard part is remembering whether I had some unfinished task lying around, or whether I can just start on the next interesting-looking piece. I’ve taken to checking in a “next step.txt” in order to keep track of where I was.

So I’ve spent today setting up a Linux VPS, configuring the web server, installing Drupal and all sorts of plugin modules for it. And it’s a painful experience. Every step I take is based on something Google tells me. I have no feeling for what I’m doing, no intuition as to whether it’s dangerous or not. So with every other step, I’m wondering – if I get this wrong, how much of the system will blow up?. How wrong am I allowed to get my changes in httpd.conf before the web server will stop responding at all?

It gives me an all new perspective on what it must feel like to be an inexperienced computer user. Afraid to click on anything, afraid to change a setting, just in case they make the computer blow up.

Another perspective on this is if it hurts do it more often. It was not meant quite in this sense originally but it still makes sense. Unfortunately it’s very rare that I have a meaningful need to tinker with Linux sysadmin tasks or web server settings.

Evolution = Variation + Selection

The equation is obvious, and yet it was useful to have it spelled out like that. The moment I saw it on the screen, I knew it was just what our Agile project needed right now.

I’d been thinking for some weeks now that our project felt a bit stagnant. Everything was going well, we were delivering good stuff, the process was flowing smoothly, but there was something missing: change. And if there’s no change, there’s no improvement, and I get restless.

We’d had our regular retrospectives, and we’d always come up with some points for improvement. But I felt that we were often saying the same thing every month, and that any adjustments we made were small, on the margin. Looking back (with that equation in front of me) the reason is obvious. We had a good deal of selection (critical evaluation) but far from enough variation. We need to experiment more, change our routines and our processes more (more often, more extensively, more deeply, more creatively) and see what happens.

The first thing we’re going to change (after we all get back from our vacations) is try 1-week sprints/iterations instead of 4-week ones. And I’m going to spend a lot of time during the summer doldrums (when we’re between iterations) thinking up more variations to try.

As with the ALT.NET events, I came home not so much with facts or techniques or tips, but with feelings of inspiration and energy. While it would have been nice to find answers, it is also nice to at least know that others are struggling with the same questions (such as fitting testing into short iterations, or adjusting Agile & Scrum for use in a very small team). The term mutual admiration society may be derogatory, but sometimes a bit of mutual admiration is what we need to energize us.

The most interesting discussion was a philosophical-political one. I cannot recall the original label for the session, but one of the topics we ended up discussing was the parallels between some dynamics of the Agile movement and “real-world” revolutionary movements. Liberation movements themselves are often very illiberal, even autocratic, and it can be hard to shift from leading a liberation movement to leading a liberated population. Very different qualities and behaviours are required.

The Agile movement is a kind of liberation movement, aiming to free developer teams from the burden of excessive management, procedure, planning and documentation. But when the message trickles through to the masses, the original leaders think the message has been distorted, lament the degradation that their lofty ideas have undergone, and start talking about the need to restart the process under a new name and a new manifesto. And the masses get upset that their leaders seem to be abandoning them.

The Agile movement is a principles-based movement. It’s not so much a method as a philosophy. (Aren’t real-world revolutions the same?) And for the leaders of the movement, principles suffice. But when the idea spreads (or when you try to spread the idea) from innovators and early adopters on to the early majority, it starts to seem that principles are no longer enough. The target audience now includes people who do not think much about principles – because if they did, they would be leaders or early adopters themselves. So processes and methods and rules start to agglomerate. “If you’re not doing TDD then you’re not doing Agile,” and so on. So there is an inherent conflict between the foundation of Agile software development (trusting people), and the desire to spread it to the bulk of the developer population (whom you don’t trust to do the right thing on their own).

(This, of course, raises a new question: should we even try? Would it be desirable to have the majority of projects run in an Agile manner? Or, as another speaker put it, are we running out of Agile developers? Can any developer work in an Agile manner, or does it take a certain kind of developer, of which there is a finite number?)

The issue of leaders abandoning a movement once it reaches some level of maturity is also an interesting one. (Lean development is one of the new new things that people orient towards when they get enough of Agile.) There are at least two forces conspiring to make it so. Firstly, thought leaders are rebels and/or innovators. In order to feel happy they need to feel that what they’re doing is new and fresh, and not mainstream. When their idea becomes mainstream, they must find something even newer. Secondly, the leaders will naturally continue to develop and refine their own ideas. They won’t stop just to wait for the rest of us to catch up. So by the time we get to Agile, the people who started Agile will again be ahead of us.

It’s fun and educational but it is also painful. The trivial tasks are trivial, but the moment I try to do something other than plain CRUD with strings and numbers, I get stuck. Every task takes me a whole evening. At this rate the application won’t be done until Christmas.

Today’s stuckness: time zones. I want to be able to migrate the data from our existing database, and CSV files seemed like a sensible medium. Exporting from Access to CSV went easily. Importing text went well enough, once I figured out that I needed to open and resave the file with different encoding. But importing dates did not. My data file had an entry for 1998-01-01 and after importing it somehow became 1997-12-31 23:00. When I got that fixed (by changing the application’s time zone to UTC) the data looked right but whenever I re-imported the data file, the dates were not recognized as matching what was already in the database, so the records were appended rather than updated. It turns out that in SQLite a date without time is not the same as a datetime with time = 0. Who comes up with this stuff?

After all, I have been working with legacy code without any help, and making progress cleaning it up, too. So why would I need a book? What can it possibly do to help, other than commiserate and advise me to refactor? For a long time I dismissed the book as “probably won’t help me much in practice”.

Well, it turns out that the book is not really about how to work with legacy code. Michael Feathers has his own, very specific, definition of legacy code: for him it means code without tests. And he also has a very specific definition of working with legacy code: for him it means adding no more untested code. Whenever a change or a new feature is needed, the affected parts of the code base need to be made testable first.

Redefining the problem from “working with legacy code” to “making untestable code testable” suddenly makes the topic appear very useful indeed, and the book turned out to be excellent. Like numerous other reviewers, I wish I had read it a year ago!

It’s full of practical advice, with lots of great examples, rather than high-level principles. Very pragmatic, where other software design veer off into idealism: “you often need to make your design worse before you can make it better” was a recurring theme here that I really sympathise with. It was a very inspiring rbook, making my fingers itch to refactor. On top of that it’s interesting, well-written, and very obviously written by an experienced, knowledgeable expert.

The book is structured sort of like a cookbook, question-answer style: “I need to make a change. What methods should I test?” I cannot imagine using the book to look up answers to such specific, disjointed questions. No, the book needs to be read and digested, and then re-read and re-digested, repeating until you’ve fully internalized all its ideas. I’ve read it once from cover to cover (skipping only the C/C++ specific advice) and I know I will be browsing it for inspiration many times. The numerous cross-references make it a very browsable book.

However. I like the general idea of making all legacy code testable, but in practice it’s not always practicable. GUI code is the most obvious example: it’s hard to test in the best of cases, and in a legacy code base, making it testable is a hopeless battle. I’m not going to refactor an entire 1500-line aspx page so that I can test my one-line change which makes a certain element invisible in certain circumstances. And more generally, making legacy code “non-legacy” is a worthwhile goal, but sometimes the change really is small and safe enough, and entangled enough, that making it testable is just not worth it. But I guess the book needs to be more categorical than reality: aim for the stars, get to the treetops.

Amazon US, Amazon UK.