406 - PurelyFunctional.tv Newsletter

00 Design process.md

Design process

This week's challenge is to describe your design process. How do you think before you build? What questions do you ask? What do you look for? Do you sketch, plan, and prototype?

Please submit your solutions as comments on this gist.

I do enjoy designing with questions, research, notes, and gradually improving diagrams, but that isn't anything that I can really claim works. My best designs are the second or third version that improves or fixes the earlier design. I never used anything other than a long waterfall process in my corporate IT work, but now I'd go with the agile approach that gets something in the hands of someone that can lovingly break it as soon as possible.

The context and expectations of a project have a large impact on its design process. The processes for a short puzzle exercise and a enterprise system are of course very different. For larger projects, resource constraints (time, cost, quality, team experience, etc) may have an influence.

One useful element I've seen in design processes for projects large and small is the use of examples to explore and validate designs. Examples communicate the desired outcomes unambiguously, in contrast to rules (in natural language) which can be misunderstood. A small project can be designed interactively at the REPL and tested against the examples. A large project may use Specification by Example (Gojko Adzic) techniques to drive the design process, engaging all stakeholders to develop a common understanding and ensuring that expectations are surfaced and routinely met.

For larger projects, I think developing and maintaining ubiquitous language (a domain-driven design concept) is crucial. A UL captures understanding of a problem domain as it grows during the project. Rather than a list of word definitions, think of the UL as a collection of phrases which model the truth as closely as needed.

Right now, when designing systems, the first thing I do is really try to understand what problem I'm solving. If I'm working with other people, try to make sure that we are all in the same page. The next step, would be to decompose things. Now, IMHO this is more art than science that would need several iterations. I'd thereby end up by composing things together into something coherent...