Design analysis paralysis

It was the start of (yet) another project. The requirements were in. The database table design was done, subject to changes if the final code needed it.

So I sat, arms on the arm rests, slumped slightly in my comfy chair. Leaning slightly backwards, I had my eyes on the ceiling, looking for inspiration, gently rocking on the chair. Shapes and colours formed and dissipated, words and numbers just barely clear enough to see.

I was visualising my user interface design.

After I had the general idea that the imagined web application user interface, required business logic and database tables were going to match, I started drawing. I pulled a few blank pieces of paper from my stash of trash paper, and drew an outline of how it would look on the web form. Panels, textboxes and dropdownlists. Datagrids, buttons, checkboxes and radio buttons.

Should the textbox take in only input of “dd/MM/yyyy” format? Restrict only numeric input? I scribbled my notes beside the interface controls on the paper.

Finally, I’m done. I’ve got arrows denoting process flow with notes on input and display output. Then I went back and thought again. Would this interface design work? Could it fulfil the business requirements? Could it support insert, update and delete operations to the database tables?

After half an hour, something inside of me screamed, “Stop this!” I’m in design analysis paralysis. I heaved myself out of my reverie, and started actually coding.

Has this happened to you before? You want to make something perfect, so you think about the design, planning it this way and that. You chew over some of the decisions, “oh that’s not gonna work well”, and rearrange some parts.

There comes a time where no more designing can help you. The only way to see if your design works is to actually start writing some code. With working code, you can test. With tests, you get feedback, with which you can correct your code.

Let me give a non-programming example, my writing of a sestina (of the poem category). Its rules are simple. There are 6 stanzas (or paragraphs), each stanza consists of 6 lines. Each of those lines must end with a word from a group of 6 words. Every stanza must have lines ending with one of those words. The words must not repeat within a stanza and they must be in a certain order. The seventh and last stanza has only 3 lines, but each line must have 2 of those special words, and one of the words must end each line. I probably confused you more than explained how a sestina works, so you might want to read it up yourself.

So what I did was come up with the 6 words first. Analysing the sestina requirements, the obvious observation was that every one of those words would be used 7 times (7 stanzas). Instinctively, I knew I needed words preferably with more than one meaning, so I don’t keep repeating the same theme.

Then I realised that if the words could be both a noun and a verb, then it’s easy to describe it with more than one meaning. So “code” can be programming code, or cryptographic code, or code as in writing code. I was stuck in a mental quagmire coming up with those 6 words, trawling through my vocabulary for words with ambiguous meanings and double entendres.

Obsessed with fitting the words, a theme and sestina rules, I got that “Stop it!” scream again. I needed to just start writing the sestina. I needed to stop designing in my mind, and start doing something.

So on my computer, I just typed out the 6 words first, one on each line.


Then slowly, I filled in the details,

Just like the life giving warmth of the sun
You can create a better world through your code
Even something as simple and mundane as water
This element of old courses the veins of a tree
With earth and air, ancient elements the other two
They fuse together, becoming a beautiful force

Each line gives inspiration for the next. Then I typed out the 6 words for the next stanza in the order required.


And I filled that as well. Some stanzas I had a theme to work with, and the words seemingly flow and automatically end with those words I chose. Some lines required a bit of nudging here and there. Some lines required changes so the whole sestina still reads smoothly.

Then it’s done. I proofread it, checked the visual look on screen and recited it for cadence testing. And it’s done. If I had still been stuck deliberating over my choice of words, I’d never be able to get anything done.

The only way I could move forward was to break out of design mode and do something. So how do you break out of design analysis paralysis? Have you ever been in one?

[To the Chinese readers out there, have a happy Chinese New Year (7 Feb)! Check out some of the decorations in my office.]

Fail to plan and you plan to fail

Recently, I was tasked with one of those improvement requests from users. The web application in question was to be enhanced to cater for more complex user roles.

“How many man days do you need?”, my team leader asked. I gave a rough estimate and said I’d have to think about the solution.

Off the top of my head, I’d have to modify some database tables. That would affect the query statements in the business logic classes. Which might mean some code changes. Then there’s the problem of displaying the data according to the more complicated user roles. And I still had to ensure secure retrieval of data.

So I thought about it. I scribbled notes. Drew some diagrams. Thought about it some more. Took another piece of paper and plopped some fake data on it. Crossed out some of the fake data. Redrew the arrangement. Scrutinised existing database schema. Compared with arrangement on paper. (Now you know why my desk is a mess) I even thought about which code parts I needed to change.

During this thinking phase, I might be

  • Sitting still and staring at monitor
  • Sitting still and staring at piece of paper
  • Staring up at ceiling with feet tapping along to music beat on my earphones

At first glance, you might think I’m doing nothing. I’m not. My mind is whirring with activity, busy displacing images, reasoning through logic and considering alternatives. I find it faster to move diagrams and table structures around in my mind than to redraw them on paper. Ideas are committed to paper when details start overflowing.

After maybe 5 days of scribbling and thinking (while fulfilling my other work duties), I felt I was ready to start actually changing code. Luckily, I was the original (and only) author of the web application, so I was already familiar with the code.

Why did I take so long then? Because I had to plan for future expansion. I had to plan for possible new marketing ideas from users. I had to plan for the possibility of someone else taking over my code. Plan, plan, plan.

When I finally fired up the source code in Visual Studio, I only had to do find-and-replace operations, minor code changes, and refactoring property and web control names. And all of that was done within an hour. Then I only had to test that the web application worked as before, with the new business rules added in. Which took up another few days.

As a programmer, some of your project tasks will have very little to do with actual coding. The real value of good source code isn’t hammering the code out in record time, but the thought that goes into it.