Where Design Fits In

Agile’08 starts Monday, which makes me feel that I ought to justify the Big Design Up Front I’m currently doing. Here’s as far as I’ve gotten:

  1. I'm thinking again about access control in DrProject. A user's membership in a project is represented by a triple (project, user, role), where a role is a set of permissions defining what can be done.
  2. The simplest model for permissions would be to define READ and WRITE for each component, e.g., WIKI_READ ("can see the wiki, but not modify it") and WIKI_WRITE ("can create new pages, or update/delete existing pages").
  3. But tickets mess this up. Open source projects often allow non-developers to file tickets (in fact, they encourage it). The only way to support this if the only permissions available are TICKET_READ and TICKET_WRITE is to give anonymous users (i.e., people who haven't logged in) a role that contains TICKET_WRITE. However, that would also allow them to modify or delete other people's tickets, which is clearly a Bad Thing.
  4. OK, so what about TICKET_READ, TICKET_WRITE_ALL, and TICKET_WRITE_OWN? Easy enough to create three permissions---but it would complicate the logic inside DrProject. It also complicates the conceptual model (which I think is actually the bigger burden).
  5. Here's another wrinkle. In every ticketing system I've ever worked with, tickets have a one-line "title" or "summary" field, then a longer "description" field. For small projects (our target market), most tickets only need the former, so I've been thinking about taking the latter out of the tickets themselves, and providing an easy way to link to specially-named wiki pages (e.g., ticket #123 automatically links to a page called Ticket123, but only if someone has bothered to create it). This neatly supports the common situation in which a "ticket" turns into something more akin to a BBS discussion, where lots of people post back and forth about the best way to solve a problem. But how would the permission system handle this? Would the special logic to handle TICKET_WRITE_OWN propagate to the wiki, so that if a page was associated with a ticket, and that ticket belong to Fred, and Fred's role in the project included either TICKET_WRITE_ALL or TICKET_WRITE_OWN, then Fred would be allowed to modify the wiki page? Just writing it out makes my head hurt...

The moral of the story isn’t that there’s a place for BDUF (which all but the most zealous agilistas would acknowledge). The moral (at least for me) is where that place is. If you’re doing exploratory programming in a new domain, there isn’t much point trying to do a lot of up-front design: you just don’t know enough about what’s possible or what’s interesting. Similarly, if this is the ninety-ninth system of type X you’ve built, up-front design probably isn’t economical either: you know the tradeoffs and possibilities well enough to avoid potholes. In between, though, where you know enough to know that there are thorny issues and delicate tradeoffs, time invested in up-front thinking is time invested well.

In the wake of posts about Shopify's support for white nationalists and DataCamp's attempts to cover up sexual harassment
I have had to disable comments on this blog. Please email me if you'd like to get in touch.