I wore a G-SHOCK for a month and it changed how I look at software development

“Oh bugger!”, I say to myself half a second after I toss my watch towards the couch 5 feet away. “Need to stop doing that.” I’m more concerned about the habits I’m forming than the watch itself. An internal monologue kicks off soon after, wherein I try to convince myself that the watch was to blame for my questionable behaviour. “It’s a toy. Minor fall damage is no big deal.” The watch in question, a Casio G-Shock GA-B2100-1ADR, can handle a lot more than just fall damage. Had I thrown it in a puddle of mud, I would have just washed it under a faucet and put it back on without checking if it’s still running. Most of my other gadgets would fail that test.

My phone can do everything the G-SHOCK does. But the G-SHOCK can do it in rain, under water, and I don’t need to buy an after market case to protect it.

However, I’m not here to wax poetic about the toughness of the G-SHOCK, I’m here to wax poetic on what it taught me about software design. For me, this was a “feeler” watch; a stepping stone towards more serious mechanical watches. I wanted to know how a watch felt on my wrist before “investing” in something more expensive. I made the purchase based on reviews I read online.

As an outsider to the watch world, I failed to understand why Casio would ship a digital watch which did nothing other than tell time in 5 different ways (time, perpetual calendar, world time, timer, stopwatch) when there are plenty of smart wearables and even smart phones that do a lot more at the same price point. Was Japan so out of touch with what’s happening in the rest of the world or was there something else going on here?

You could argue that smart wearables have made watches, especially the digital ones, obsolete. But pay a little more attention and you will find it to be a very well-designed product.

What started as an ornament for my wrist became a part of my lifestyle in less than a week. It woke me up in the morning with the alarms, showed me the date so that I could check for expired groceries, and timed my rest intervals during workouts. Before logging in to work every morning, I would switch the digital display from date to second time zone, which was set to UTC (if you know why, you know). Switching it back became my logging off ritual. A watch enthusiast would tell you that there’s something charming about using it to tell time, “It makes me feel connected to the flow of time.” I just found my watch to be a better tool for telling time, or the other 4 time related functions it has. Had I bought a mechanical watch, I would’ve just worn it and enjoyed it for what it was. But having a digital watch on my wrist while I wrote code compelled me to draw comparisons between the design of the watch and what I was building.

Two analog hands, one mode indicator, a tiny digital display and four buttons for input combine to form a more intuitive interface in this watch than most web/mobile apps I have seen.

I have seen UI designers unable to accomplish with 4 full screens what this watch does with 4 buttons. You can run the timer and stopwatch concurrently, switch to the date display and then come back to them. All the relevant information is available on the dial all the time. There are no secret button sequences to memorize; each of the four buttons has a designated function irrespective of the mode selected. There are several watches in the G-SHOCK line that include step counters, calorie counters, altitude meters et cetera. But not this one. This one was designed for timekeeping; it does that with utmost perfection.

Shouldn’t the principles that we follow as software devs be the same? So often product owners pile up half-baked features to compensate for poor design. When we are told to improve, we lean towards adding more instead of bettering what we already have. Engineering teams lose all sense of direction, having no clarity about what they are trying to build. It is always tempting to expand the scope or the number of features. After 3 years of building and maintaining Quick Copy, a trivial endeavour compared to the one I’m writing about, I know that it’s hard to draw a line in the sand and ship what you already have. It takes guts to say that “This is what it is. I cannot add any more features without taking something away from what’s already there”.

We try to add in quantity when we fail add in quality.

Software design and watchmaking are poles apart. Software progresses faster than any other field in engineering that I’m aware of. But should our “smart” products get outdated as well? Should we need to buy a new phone every 3-4 years because it will get “outdated”, and hope that the new one doesn’t break down sooner? What are we really improving? Online forums tell me that my watch could run for the next 20 years. And I’m sure it would still be the best perpetual calendar/timer/stopwatch/world timer. Why do I not feel the same about my phone, or the smart speaker gathering dust in a corner of my room? Adding WI-FI connectivity, a long sign-up process, collecting personal information, and using machine learning doesn’t build better products. You can find artificial intelligence in NPM packages but you cannot import good design from a library.

One last thing, did I tell you how to charge the G-SHOCK? You just keep it under the sun every once in a while.