I recently read an article by Ryan Brush that imagines a world where construction jobs are done by cheap, accurate robots that can fabricate materials out of thin air. As the cost of building approaches zero, the success of a project becomes dependent solely on the blueprints. Give them a plan where walls don’t meet…they’ll build it perfectly wrong. You can just tear down and rebuild, so there’s less incentive to get things right the first time. He calls this dilemma a design crisis.
As frameworks and tools increasingly remove grunt work from modern programming, this design crisis scenario resembles software creation more and more. At some point between taking requirements from a client and deploying the finished product to a production environment your team is going to need to design. Design isn’t limited to visual design, but encompasses the full technical plan for turning requirements into software. It requires a lot of communication from everyone on the team, and it’s a difficult step to get right.
So where does the communication for this planning happen, how do you get those blueprints hashed out and committed to record? There are two primary venues I’ve seen used to host this dialogue: tickets and meetings.
Tickets (aka ‘issues’, ‘bugs’, ‘cases’ depending on your flavor of app) are a collection of entries in a software tracking system designed for this type of dialogue. A ticket’s ‘title’ and ‘description’ describe the core of the issues at hand. Participants are invited and can comment in response to the initial entry. It is this dialogue among a select group that gets a ticket to its final state. The bulk of tickets are usually created by a technical project manager or an architect who is responsible for turning the requirements into software, although it’s appropriate for anyone on the team to start one.
- Ticket dialogue is asynchronous, and gives people a chance to chime in when they are free and after giving some thought to the issues. If you work with software developers, chances are you have some thoughtful colleagues. Allowing this extra time for reflection can often bring out their best.
- The discussion and any decisions you arrive at are documented in perpetuity. This can be important for the long-term success of a project. After releasing a feature you may not revisit it until months later, when you may be left scratching your head: “Why did we implement this craziness?” The ticketed discussion reminds you it’s built that way so that the system doesn’t send infinite retries to the poor server on failure.
- Writing and finalizing a good ticket can take more time that implementing the feature set it describes. Why is this a Pro? Because it means you finalize the blueprint before you start laying the foundation. Nothing is committed to code until a thorough discussion takes place, and the implementation often goes quickly as a result.
- Design tickets segue nicely into implementation tickets, either by reusing the same ticket and giving it a new title, or as a reference for the action tickets that come out of it.
- Good luck if a participant is skimming, or the creator hasn’t clearly stated the facts. Ticket creation requires a very particular type of writing skill. Complex and abstract questions must be structured and presented in a way that doesn’t confuse more than illuminate. Poorly-written tickets usually spawn discussions that resemble Who’s on First.
- A discussion that might have taken 15 minutes in-person can stretch into days. You can try to mitigate by setting a time limit, but this can be difficult to enforce.
- One of the most dangerous things about tickets are the questions that don’t get asked. This is a possibility with meetings as well, but there is psychology at play that makes it a particularly dangerous pitfall for this method. The initial batch of ticket creation for a new feature can give a false sense of completeness if there isn’t some careful reviewing to see what’s been missed.
Getting people in a room still has a lot of power, even in the digital age. Knowing when to schedule a design meeting, and who to invite, is almost an art. Ideally it happens when the design questions are somewhat defined and there aren’t any significant unknowns for requirements. You want to invite enough key players to give the session the firepower it needs but not so many people that it activates “committee mode”. I’ve found the best number of participants is 3 to 5. Once you have all your participants assembled (corporeally or non-), you can get to work.
- Humans evolved with verbal language and instantaneous feedback: expressions, gestures, and tone. There is no substitute for the bandwidth possible when all these are present. I’ve seen issues that go nowhere after a dozen back-and-forth written exchanges get cleared up with a 15 minute face-to-face.
- You can use whiteboards and projectors to assist, real-time. The first time someone gets up to write something on a whiteboard, it crystalizes the abstract and focuses attention. Ideas that were previously just words become data models, sequence diagrams, and bullet lists, and without investing time drawing them with software. The projector opens up a world of pre-existing reference materials for everyone, be it an important email only one person was CCed on, an XML schema that informs the decision at hand, or a search engine result to a question that arises.
- Real-time documentation creation. As part of the discussion you can actually create and modify the documentation you’ll want to implement from. Undertaking this also has a way of focusing the discussion and reducing the number of tangents.
- Brainstorming, or the “sounding board effect”. A meeting allows rapid exchange and refinement of ideas that can produce a whole greater than the sum of its parts.
- Those same ancient communication dynamics can be counterproductive. If you have dominant personalities and others that are easily spooked, a meeting of the minds quickly becomes a one-way street. Hopefully whoever’s doing the hiring in your org has checked the emotional intelligence of applicants in addition to their technicals chops, but if some characters have slipped through at least be sure someone is present who can help moderate some of the extremes.
- The flip side to the Pro bullet: without written minutes, it’s all for naught. Good software people are passionate about what they do, and arguments can get almost religious in zeal. I can’t tell you how many long, painful meetings I’ve attended where the parties gradually abandon their irreconcilable positions and reach consensus, only to have those hard-won compromises vanish from memory follow the meeting. Without someone scrupulously taking notes,and sending them out within a few days of the meeting, you might as well not have met.
- Tangents. Participants sometimes treat a meeting like Open Mic Night. Whatever topic or question they’ve been dying to talk about, here’s their shot! Meetings can fail to resolve the issues at hand unless everyone (or at least one person who can act as the group’s conscience) exercises discipline.
I should be clear that most design efforts end up using some combination of these two forums, often in parallel. Both venues have their strengths and weaknesses, the key is to know when to pull out the right one. The list above offers some guidance, but the particulars of the team and job you are working with will dictate which should be leaned-on more heavily.
The end result of these design discussions, wherever they occur, should be documentation of the decisions and approaches chosen. This will always mean implementation tickets, but wiki definitions, sequence diagrams, schemas, data models, and other forms are all other likely outputs. Making sure you end up with these assures the effort you put into design will pay off in the long run, as well as the next release.