Why Do We Bother Conduct Whiteboarding?

Some of us think it will be more efficient by directly jumps to code about what we want to do. This is fine in certain situations.

For example, if you are really experienced in the domain / stack you will be building on.

Eventhough, in that situation, whiteboarding is still beneficial, okay, I know, you might want to save time by skipping whiteboarding altogether.

Why would want to skip it? Because you think it’s waste of time and just a redundant piece of work.

Or, for even worse reason, some of you feel difficulty in doing whiteboarding than jumping to coding.

I think, you must understand this:

You can’t do whiteboarding (effectively) indeed when you have NO solid knowledge and experience on the matter.

That’s why some people find it difficult to sit and design something in the whiteboard, because it requires knowledge and experience.

And you can’t expect junior developer to flesh their thought and pour it to good design in a whiteboarding session.

So having knowledge can be double edge sword, first, it is a good indicator that You can perform effective whiteboarding.

But, also, having knowledge can makes someone thinks they do not need whiteboarding altogether.

Now let me tell you this:

You don’t have to do whiteboarding, but if you want to improve you must do.

Yes, that’s the key, improvement.

Here is an example of why I wrote this blog, I have solid experience in React but using Electron? I do not have a single experience doing it.

I need to build an app for Mac using Electron.

Now, If I want to start with whiteboarding, I’ll be stuck staring at the blank canvas.

So, instead what I do is of course read the documentation, get some relatively popular boilerplate, understand how they works.

Then I directly jumps to code to create basic working prototype.

After this, I know I can improve the code to understand better how Electron works. This time I still do not perform whiteboarding.

Using my limited knowledge, I keep refining my codebase architecture adding components and services, modifying, changing, replacing, reverting and so on.

Until I pretty confidence about the architecture that I’ll use.

And then, I felt I could improve more on the architecture, I need the codebase to be organized well but at the same time simple and effective.

I want something I call “productive electron architecture”.

So then I draw my current architecture that I build directly by coding. It turns out like this:

After looking to this diagram, it turned out, it’s easier for my mind to spot something that feels redundant and produce too much boilerplate without adding value.

From there, I experiment by removing one thing, re-draw the diagram to reflect the change.

I looked at it again, and again my mind had new idea that another part could be changed or even removed, I experimented again in the code, and yes it works.

Until finally I got a simpler version of the previous architecture that improve the DX and clarity. Like this:

In this moment, I realized that whiteboarding do not necessarily need to be done at the start, but one can do it when they want to improvement.

Remember, we need knolwedge and experience to perform effective whiteboarding.

If I directly go to whiteboarding in above case, I’d be having hard time, I didn’t even know what to write on because do not have enough hands on the Electron architecture..

Summary

Have no knowledge?

CODE -> WHITEBOARD -> IMPROVED CODE -> REPEAT (if necessary);

Have solid knowledge?

WHITEBOARD -> CODE -> REPEAT (if necessary)