IT Leadership, Counselling and Execution
Business
Modeling
02/02/16 16:50
Architects have it right. When commissioned to submit a construction design, they do more than write words describing what the client (thinks/says they) want: they draw what they have in mind so that they can share it and they build scale models, or virtual representations of the end result so that clients can see exactly what it will be when done.
A couple of years ago, I was lucky enough to go through the experience of building a new home for my family and got to work with a highly talented architect. Matt, obviously, sat me down at the onsite of the work and asked me what I wanted the property to be but he didn't just ask us and have us talk back at him - he showed us examples and had us tell him what we liked and what we did not like; he asked us to point out materials and finishes and shapes; we drove around looking at other properties, and, generally obsessed details such as roof tiles, brick colours and window-frame finishes. And when he came back to us with his initial designs, unsurprisingly, his proposal was more than just words on a page describing what our house could be. Just as well! He gave pictures, drawings from all angles and an app that had us able to walk through every room in the house before the old one had been knocked down.
Building a system should not be any different. What is the point in writing 60 pages of specifications which is only "correct" for a short moment in time and in the mind of the person that wrote it? Even if they read the entire spec, other people will have their own thoughts on how it is supposed to look and feel and behave and, fundamentally, what it is to do - interpretation will be so wide and will vary so much that this form of design as inappropriate for software as it would be to build a house (or a bridge or a tower or a boat or a car) without a picture or a model.
Build something, however un-functional, so that people get to see it as soon as possible - show it to them often and, as you are building the finished product, adopt a mindset of involvement, sharing and prototyping. Constant and critical input will save expensive (time and cost) rework later.
A couple of years ago, I was lucky enough to go through the experience of building a new home for my family and got to work with a highly talented architect. Matt, obviously, sat me down at the onsite of the work and asked me what I wanted the property to be but he didn't just ask us and have us talk back at him - he showed us examples and had us tell him what we liked and what we did not like; he asked us to point out materials and finishes and shapes; we drove around looking at other properties, and, generally obsessed details such as roof tiles, brick colours and window-frame finishes. And when he came back to us with his initial designs, unsurprisingly, his proposal was more than just words on a page describing what our house could be. Just as well! He gave pictures, drawings from all angles and an app that had us able to walk through every room in the house before the old one had been knocked down.
Building a system should not be any different. What is the point in writing 60 pages of specifications which is only "correct" for a short moment in time and in the mind of the person that wrote it? Even if they read the entire spec, other people will have their own thoughts on how it is supposed to look and feel and behave and, fundamentally, what it is to do - interpretation will be so wide and will vary so much that this form of design as inappropriate for software as it would be to build a house (or a bridge or a tower or a boat or a car) without a picture or a model.
Build something, however un-functional, so that people get to see it as soon as possible - show it to them often and, as you are building the finished product, adopt a mindset of involvement, sharing and prototyping. Constant and critical input will save expensive (time and cost) rework later.