Design Thinking
I watched the first part of the documentary series Abstract on Netflix the other day. If you’ve not seen it, go check it out, it’s great. The first episode focuses on the illustrator Christoph Niemann, and cleverly incorporates his work and style into the shooting of the documentary, as well as outlining his approach to his work and thoughts on creativity. I found it really inspiring, and it made me think about how I approach my work as a software developer.
Software development is still a relatively new discipline, and it sometimes feels like we are looking to more established fields as a guide to how we should be doing it. Are we engineers? mathematicians, craftspeople? We mine ideas from martial arts to manufacturing looking for insights. But watching the documentary it occurred to me that maybe we are missing a trick in not looking to designers for some cues.
Of course, people have long talked about design in relation to software. In the old days, it was that step that came after requirements specification and before implementation. Then agile came along and having a “design phase” became anathema (BDUF!). In its place was either many small design phases, TDD inspired “emergent design” or perhaps no design at all, just the “out of the box” design that comes with our chosen framework. There was the design patterns movement too I guess, although that seemed to tend towards people thinking of cookie cutter rather than experimental approaches. There is always architecture of course, which is apparently the only kind of design still strongly encouraged to be done “up front” (though still “just enough” of course!)
Occasionally I have heard people voice the idea that maybe design is something that we are doing constantly and incrementally, but I don’t
recall seeing that idea explored too much. But here is the thing. What if design is all we do. It’s not separate from implementation, or testing, or requirements gathering. Its all just design. Because in manufacturing or construction, there is a clear separation between the design of the thing and the making of the thing, but in software it doesn’t really work like that. Like an illustrator, we don’t hand over some outline of a drawing for it to be “made” by someone else. We hone, and refine and tweak our design, expressing that design in code, working our way towards something that “works” until we decide it is complete or we run out of time.
Now this view, that everything we do is design, doesn’t seem too outlandish to me, to the extent that I wonder if everyone already thinks about what we do in this way. If that is the case it doesn’t seem to come over in the discourse. We don’t call ourselves designers, apart from some front-enders, though again I think there might be resistance to the label, perhaps because it doesn’t seem technical enough. But maybe all types of developers should embrace the term. And perhaps maybe stakeholders would start to think less of specifications to be met, and more of briefs to explore. Emphasising the collaborative over the contractual. Maybe developers would be a little quicker to discard an idea and try something else, if it was just a design we were rejecting rather than a half finished product. Maybe we could find ways of working which maximised our chance of capitalising on those rare moments of inspiration instead of targeting the monotonous churn of a production line.
