Design Development and the WYSIWYG Trap, Part 2: Construction and design development
Applications are digital spaces. What can the software industry learn from architecture and construction workflows? This is the middle of a three-part article, so please read Part 1 first.
What is construction in software
After reading the Moss Design guide, you now know how a building comes to exist as digital models. It starts from sketches, proceeds through design development, and ends with final construction documents that provide details of everything needed to actually construct the thing — structural drawings, electrical plans, surface material specifications, and so on.
With the construction documents at hand, a building needs a permit to actually get built. There’s no such thing for software though; neither do we need contractors and manual laborers to build the thing. Instead, the construction of software is an automatic process performed by the computer based on a set of instructions.
These instructions, our “construction documents”, are source code. The “building” that a user visits is really the application’s state that exists in memory on one or more computers. This transitory edifice is built out of executable machine code and digital assets according to an exacting construction plan laid out by programmers. This is true whether the application runs in a web browser, on a server, on a mobile phone, or using the APIs of a desktop operating system. We can imagine a “robot contractor” who performs this construction job.
For very lightweight software, the construction happens on the fly as instructions come on, e.g. entering commands into a command line, or “inlining” JavaScript code directly into a web page. This is the software equivalent of propping up a tent — you don’t expect the construction to be permanent.
Most real applications have a formal build process, though. Software development tools all have a command labeled Build, like in this menu in Apple’s XCode:
(Architects dream of this command. Build it up, tear it down, try again as many times as you want! No materials, no permits, no environmental cost.)
A click on the Build button effectively reads in all your construction documents and runs them through a compiler — that’s the “robot contractor”. The compiler is typically smart enough to offer you early feedback (in the form of cryptic error messages) if your documents are obviously wrong, just like a city planner evaluating your building permit application might. For something like the Apple XCode compiler, the output is a sequence of machine code for the CPU — the equivalent of “atoms” for your digital spaces.
Web applications don’t build directly into machine code, but they also use compilers. Tools like Webpack are used to manage the complex process of collecting assets and JavaScript files, often transforming them from intermediate languages like Typescript, and bundling everything together into a tidy compressed package that can be sent to the user’s browser. For a web app, all the input files that are provided to Webpack are effectively your construction documents.
Engineers who produce construction documents
Remember all those different types of drawings created by engineers? Structural, mechanical, electric, plumbing, landscaping… These are all created by specialized engineers who studied for this particular job.
The work of software engineers today tends to be similarly specialized; they just produce code instead of drawings. A back-end software developer who wires up API calls into databases is doing something not all that different from a plumbing design engineer. For both, the work is often essentially the same from one job to the next — but you can’t afford to slip on the job, or there’s going to be shit on the floor. (A significant difference is that the back-end developer is often frustrated with her work because she studied something called “computer science” and was hired based on a theory-oriented whiteboard interview that ends up having nothing to do with the repetitive reality of the job. The plumbing engineer never gets asked to perform a mini-lecture on organic chemistry as a job requirement. But I digress…)
Dependencies
Within the CSI steps, we saw that “construction documents” was surrounded by “product selection and evaluation” and “procurement”. These actually have a useful analogy in software development, namely the selection and use of dependencies.
Very little software development these days is “blank slate”. Most of the time, developers can expect to be making use of dozens or hundreds of dependencies — software libraries and tools created by others and usually made available as open source. They are typically distributed and installed through package managers.
In my opinion dependency management is an underestimated component of software project risk management. On average teams should probably be spending more time understanding their dependencies, and especially thinking about whether they really want to take on a particular dependency. Easy package managers have made the long-term maintenance cost of dependencies hidden from sight when it shouldn’t be.
The construction analogy is helpful if you think of dependencies more like products used in construction. Would you build a million-dollar house using cement and steel that some random guy on the street was handing out? Would you use a hundred slightly different products within the same project? You’d probably spend a bit more time to ensure the materials are of quality. Shouldn’t the same critical rigor be applied to the selection of packages available on npm (or whatever is the distribution system for your programming environment)?
Design development: the missing link
The software industry has no shortage of designers who are regularly disappointed that developers don’t seem to build what they designed, and simultaneously developers who are disappointed that designers don’t seem to understand what can be built. This is a much rarer occurrence for buildings. One reason is that a plumbing engineer simply doesn’t get asked to divine their specialty’s requirements based on a rough façade sketch where the architect has added a red line that reads something like “Water stuff happens here”. Instead there is an important step in between called design development, as you’ll hopefully remember from the Moss Design guide.
This is the phase where the software industry needs new kinds of tools to be able to even approximate what the construction industry does. To better understand these tools, let’s turn to market leader Autodesk.
I’ll use as reference an online class called “Design Workflow from Concept to Construction Documents” by Autodesk. The nice thing about corporate educational materials is that they’re mostly free of marketing talk — someone who has signed up for this course doesn’t need to be convinced that design development is necessary or useful, they just need to be shown how it actually works today. This course presentation is freely available through the above link, but you need to sign up for a free Autodesk account. So that you don’t need to download the whole thing, I’ll present some selected quotes from the presentation as low-res screenshots next.
Replace “construction documents” with “code”, and the question posed above is acutely relevant for software design.
See that pencil sketch on the left? Pretty as it is, it’s a long way from a model that can be used for facilitating construction. For the software analogy, imagine a low-fidelity UI wireframe or pixel-perfect Sketch rendering there. This is an important point: It makes no difference whether your conceptual design drawings are “high fidelity” or not because they’re still not models — just as it makes no difference whether the architect’s pretty perspective drawing is made with a rough pencil or finely detailed watercolors.
We’ve already seen most of these process steps described before. We know “schematic design” in software terms is the conceptual phase, the realm of the person who goes by titles such as product/UI/interaction designer. But what is “BIM execution planning?”
From BIM to AIM
BIM is short for Building Information Management. The closest equivalent in software would be the combination of unit testing and live app monitoring — i.e. the practices and systems that aim to prevent failures when a software system is actively developed, and to provide developers with data about how it’s actually being used. There’s a huge difference in approach though: software tends to bring in these “information management” practices during latter phases of development, whereas the construction industry is thinking about all this stuff as early as possible, already during the design process.
Have you ever met a designer in software who plans for things like unit testability, dependency management, usage data gathering and their combined feedback loops while working on interface designs? I haven’t. But I want to stress that this is not really a failing of today’s UX professionals. The architect isn’t expected to think deeply about BIM — there are other professionals who manage this phase of design development.
For most software corporate projects, the project scope that closely matches a building is the application. The term AIM, Application Information Management, comes naturally. I don’t know if it’s a moniker that can stick, but we can use it as a mental aid when studying construction industry practices: replace “BIM” with “AIM” and imagine what that would mean.
The important point here is that the software conceptual designer shouldn’t be expected to think deeply about “AIM” and design development, any more than the architect is a BIM expert. Instead we need one or more new roles: people who understand both design and development requirements, but are not conceptual designers nor traditional software developers.
These roles fall under the general umbrella of design developer. This is not a single job title: these are not “unicorn” roles that require the rare talent who can do both code and visual design as well as the experts! Instead, design developer roles should be narrowly specialized so that they can be reliably trained for — just like the design engineer roles that exist in the construction industry. A bootcamp-style education could potentially be ideal for these jobs, as long as the supporting software tools are there. Tools are key: without them, we’ll continue to search desperately for “10x software engineers” and “rockstar designers” whose superhuman abilities could make up for the lack of scalable process.
Now, please turn to Part 3 for the conclusion of this article!
