Are Designing and Building Part of the Same Process?
- May 19, 2014
- 0 Comments
While at SXSW interactive, something that MIT Media Lab’s Joi Ito said really stuck with me.
First, he expressed the idea that when tools fade into the background, consciousness gets out of the way and you can produce something more like art (think paintbrush). Related, the idea that learning is intuitive rather than cognitive… I think Ito was speaking to qualities of the tools and interfaces – if they’re well-designed and thought out, they fade into the background, and we should strive to create and develop such tools. But the other side of the coin is that if you practice with any good tool often enough and long enough, it will fade into the background and it will be natural to artist or craftsman.
Second, that participating in the build process is an critical component of your ability to add value to the design process. Ito advocated strongly for designers participating in building what they design. He gave a few examples – people in Shenzhen making new models of phones every week, as they learn from building, redesign, alter the build process, and then repeat the process again. Effectively, they are hacking the manufacturing equipment to produce new models – because they are so familiar with the tools and means of production and can learn from each other. Ito advocated that designers need to build. They need to experience the process of building in order to imagine and refine their designs. The process may lead to designs that are easier to build, or to tools that make building the designs easier, or to new products not imagined without the experience of building. You can see this approach in the way Apple builds products – designing new production methods in parallel to new products (a common example of this was the lasers they used to etch tiny holes in their unibody Macbooks to provide battery indicator lights – they had never been integrated into a mass production process before Apple’s design and logistics team kicked in).
The reason this thread resonated with me is that it applies so well to how good software developers approach their craft. Sure, your job is to write software. But the good developer invests in their own process and tools – and in turn, they learn techniques that inform future design. Not too long ago someone on our team was using NodeJS not just to run a server for the product he’s working on – but to also to run the build process – creating a WAR file and posting it to the Websphere application server, for example. So he had essentially invested in the tooling to make it faster to iterate his designs into a test harness and the target deployment environment.
When I worked at Lombardi, one of the developers there rewrote the build system to use Lombardi’s BPM suite to build and test the BPM suite… And one of the main traps for software architects’ and designers’ careers has always been that they would lose touch with how to build the software- and as a result make poor design decisions.
If you’re looking to be a better software engineer or architect, think about investing in your own personal software process and tools, you’re going to learn a lot about how you approach software development along the way. And when you’re done, ideally you’ll have a much better personal software process.
All the work that goes into not just software development, but developing the means of production of software along the way, reminds me of this Steve Jobs quote:
If you’re designing, just don’t forget that the craftsmanship doesn’t stop with the design, it includes the means of production as well.
Do these Ideas Travel well to BPM?
Let’s apply these two ideas to BPM. First, we’d ideally like to have BPM modeling tools that are so intuitive that they fade into the background and do not disrupt our thoughts about the business process itself. Companies like Signavio and products like Blueworks Live attempt to do that by providing various means of input and giving authors the ability to model without too many technical details. But there’s a long way to go before our BPMN authors will feel like artists.
For the second thought – that participating in the production is necessary to improve and refine the design – this can be applied to BPM projects almost trivially. Those who are designing the business process can take time to participate in it – either by sitting side by side with someone who operates in that process every day (likely, multiple people because processes typically span several roles and departments), or by doing some of the work directly. This hands-on experience and/or observation can dramatically improve the design of the business process and uncover new opportunities for improvement.