Create better software by starting on paper
Today I read an article on the Wall Street Journal about the benefits of taking handwritten notes over taking notes electronically. It’s a great article and I have seen parallels in my own professional work.
For years I have trained computer programmers and others in various technology roles. I have observed a similar effect which has led me to make a case for starting with what I call a “blank canvas”. I try to explain that one of the reasons it is ineffective to start with technology, rather than a blank sheet of paper, is that the technology immediately imposes limits and artificial decisions on us. Writing in the margins is easy on paper, buy hard in a computer program. Symbols are hard on a computer, but easy by hand. Orientation and connecting ideas are difficult on a computer, but easy on paper. Fonts, styling, etc. are a distraction on a computer, but don’t affect a hand note taker. Each bit of software designed to capture ideas pre-supposes certain aspects of format and approach, which force the note taker to conform to the technology. The hand note taker, on the other hand, can mix formats and approaches with virtually no effort.
My first instruction to any new programmer I teach is to turn of his display or close his laptop and write by hand the thing he’s trying to accomplish. This always reduces time to implement, reduces bugs and results in more extensible software.
There are several reasons this reduces time, bugs and results in more extensible software. The process of writing things out by hand forces the programmer to start at a higher, more abstract level and validate what he is designing into his software. More of what makes it into the design addresses the problem being solved. A good high level design is more easily translated into sensible classes with well defined responsibilities. Higher level design also more naturally encompasses consideration of related systems and processes, which results in more natural integration points. The software is more extensible. Starting on paper also leads to more appropriate technology selection, such as programming languages and datastore technologies.
When a programmer starts with the computer instead of paper, he is more likely to find himself answering low level questions about whether his chosen technology can do certain things. He begins to cobble together what he thinks the application should, which results in messy logic and lacks clear boundaries between responsibilities. The software that emerges lacks clarity, is difficult to test and often suffers from hard to find bugs as a result.
As in the classroom, so in software design. Do yourself and your project a favor and start on paper.
You are such fun. Thanks for making an extension to something new. I am still fighting (in my mind, not so much on the ground)the educators who keep pushing for kids being taught through the technology. This last week our school had its final review by the North West Accreditation team. We got dinged because not enough of the classroom instruction included kids on machines.
I am glad I am as old as I am.
Tom
[…] When designing systems and formulating outcomes, I prefer to think of all activities as exclusively executed by humans. In other words, ignoring any technology or tools, how would a human produce the desired outcome. For example, rather than say “an onboarding representative should email, call or fax the client to request specific information“, simply say “an onboarding rep should request specific information“. Leaving out the medium by which the request is made invites creativity and clarifies business outcomes. This is similar to why I suggest always designing software on paper first. […]