Why minimalist software wins at workflow

June 26, 2009

Recently I’ve been evaluating software to help support agile/scrum development on our team, and ideally to roll into our NASA Code product for others to use. We’re already married to Trac, so we’ve been playing with Agilo and are looking at some of the other agile plugins for Trac. Unfortunately they’re all so heavyweight, despite some that claim not to be.

I came back to a realization I’m sure a lot of us have had: most software sucks. Especially software that’s intended to augment some real-life process. When asking Timothy Fitz (my insight into the amazing continuous improvement processes used at IMVU) about recommendations on agile tools, he said: “a board and post-its (seriously)”

This is part of the reason most enterprise software sucks so terribly. Enterprise is about lots of real-life process and workflow, and given that process augmentation software even in small doses generally sucks, large amounts of it will suck exponentially.

A lot of us have learned that less software is more effective. One major attraction of Trac was their goal of staying out of the way through minimalism. The trick with minimalism, in general, is knowing what’s actually important—the essence of the message or design. This is a big part of my design process. Asking, “How can I fold these requirements into fewer features and UI?” instead of directly implementing a feature for every requirement.

The other thing about minimalism is that, like abstraction (another form of compression), everything you leave in the design makes such a huge difference. In programming, when you make abstractions, you’re deciding what you can assume. This means abstractions can go in different directions depending on the assumption requirements of what’s going to use the abstraction. The risk with minimalist software is that a simple design choice can drastically change the direction of the abstraction and make or break whether the software fits your needs.

Luckily, minimalism buys you a sort of abstraction that can enable projection. By this I mean that users can project their actual process and workflow onto the software. If it doesn’t have features that impose a particular process, users are free to do what works for them. This is why wikis are so powerful.

Coming back to Timothy’s “a board and post-its” remark, why do you even need software? If you can do it without software, why would you want to bring software in to slow things down?

Software does have a couple strengths. First, it encodes process in way that means you can automate parts of it. Nobody has to worry about manually typesetting when using a word processor. Second, it persists and organizes information that would normally be lost in handwritten notes, or worse, somebody’s head. The trick is getting these advantages without getting in the way.

A naive approach to software design is thinking that perfectly modeling a system, such as your development process, is the way to good software. I used to think this. It sounds great because then you can programmatically reason about every aspect of the system. But in the real-world, no two systems are exactly alike. In fact, a given system can change quite a bit in its lifetime. So there’s really no point to modeling systems with that kind of precision.

However, I’m seeing a lot of this in agile/scrum software. Requirements have stories, stories have tasks, organized into iterations and releases. CRUD for every noun mentioned in scrum. This on top of abstractions in a direction different than we need. Numbers where it doesn’t really matter. Nice pie chart breakdowns we’ll rarely use. Top it off with horrible UI, since with all these features there isn’t time to make them easy to use.

Honestly, Pivotal Tracker seems to have the best abstraction of agile. It folds requirements, stories and tasks into just stories. It automatically and dynamically creates iterations and calculates velocity. It keeps you on a single page, keeping you focused on what’s important.

Unfortunately, we can’t use Pivotal Tracker since we’d need it on our servers and the licensing they offered doesn’t scale if we want to essentially give it away as part of NASA Code. It’s likely I’ll want to just start nudging Trac in the right direction using Pivotal Tracker as a model reference, pulling together code from Agilo and other plugins. If there’s one thing that complements minimalist design, it’s an extension architecture, and Trac has an excellent plugin system.

Anyway, as far as augmenting process and workflow, I’ve always liked the idea of starting with a wiki and lazily formalizing the process into custom software as needed. As long as you can keep it under control, mind your requirement abstractions, and avoid writing too much software.

7 Responses to “Why minimalist software wins at workflow”

  1. Ray Says:

    Yeah, too many products assume and constrain the end users work flow. This is particularly ironic in “agile software” that should prefer “individuals and interactions over processes and tools”.

    You might want to take a look at Task Analytics ( http://task-analytics.com/ ). All it does is convert your todo list into burndown charts. Very simple.

  2. Lloyd Budd Says:

    Termie turned me on to Pivotal Tracker. I was surprised that there is no SCM integration.

  3. scaryreasoner Says:

    “Nobody has to worry about manually typesetting when using a word processor.”

    Before there were wordprocessors, pretty much nobody worried about typesetting PERIOD.

    Typesetting is a luxury, not a necessity.


  4. Automation is my favorite part of programming. People say typesetting is a luxury … I disagree, you write it once and it’s a standard for all future apps.


  5. Really nice post; most of the time we can keep things really simple and stupid and they does the job. you really don’t have to go for heavy wait applications.

  6. Chris Chris Says:

    We recently started using Tracs with Agilo and while I agree there are some frustrating aspects to having meaningless pie charts and numbers where they shouldn’t be, it seems like a good first try at trying to capture what we need in a well defined process. As you mentioned the advantages of the electronic medium are keeping details from being stuck in someones head, etc… I would also add the ability to have a shared medium further than just the white-board (I believe this becomes ever so important after the sprint has been “erased”). More so, I think some of the ‘features’ can lie dormant until needed; as we started with just stories and tasks and realized that there were some very long term themes that we needed to capture that led to capturing the (Agilo) requirement. What is nice about this (sans having to try and get used to verbiage) is that as we have begun to fill in tasks we effectively categorize them which helps nicely in the next sprint prioritization.
    Perhaps I could be looking at this from rose colored glasses as I come from a background of having to live in extended customized workflows that would feedback into essentially a waterfall life cycles…

  7. Isaac Says:

    Everyone loves it when people come together and share opinions.
    Great website, keep it up!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 25 other followers

%d bloggers like this: