Programming for the two big I’s (4): What does it mean to program without a design?

(This is the fourth installment of a story that started here.
The next episode is here.)
Generally speaking, it’s a disaster to write code without designing it first. This is like building a building without making an architectural plan or preparing supplies and schedules in advance. The primary risk is that the thing will never work, like a bathroom with no drains. In my case, that risk was somewhat minimized by the fact that we had a well-defined specification of what the software must do. But the risk was real; we were just going to be lucky.

There are plenty of other downsides to having no design. The code is much more likely to be unmaintainable. By that I mean that in the future, it might be impossible to ask anyone to make corrections and add new features. (The code probably WAS unmaintainable, and I’ll discuss the unlikely result of this later.)
The code was also likely to be inefficient in every imaginable way. I’m sure it was four or five times larger than it would have been if carefully designed. But at this time we were entering the computer era of cheap memory and fast processors; efficiency turned out not to be an issue.

People talk about “building without a plan” all the time, but what really happens? Here’s my grandmother describing a skilled worker who built a house for her family: He lost the plans but reckoned he knew how to build a house without any plans. This resulted in a few peculiarities such as corner rooms with one window, a bathroom opening out of the dining room, and coats of white paint over some of the beautiful oak wood-work.