Sanding Early

From time to time, I’m confronted with the notions of “technical debt is acceptable this time”, “let’s make the simplest possible version of this” and “no one will notice - we’ll make it good and pretty later”.

Of course, life is complex, and from time to time it makes sense. From time to time. I think users can be more discernable and critical than those sentiments give them credit for.

As probably most software developers, I’m not a huge fan of the appetite to make software cheaper, especially at the cost of quality. It’s a modus operandi in enterprise software and I find it quite mean to give people who don’t love their job more than anything else in the world more reasons for it to be that way, for example by having them use subpar software. It just makes for a more depressing reality.

I definitely appreciate the fact that sometimes rapidly shipping features is impressive and can shift the project into the spotlight, securing future investment for example. Still, my perspective on it is that there are things that are almost equally as impressive, but which at the same time make developing things feel less like work. And being impressive in enterprise software doesn’t always require taking on a massive challenge. Sometimes it’s the little things that count.

Polishing Early?

For a long time I’ve called myself a chronic polisher and a perfectionist, struggling to let go of things until I found them to be presentable. But that doesn’t mean I obsessed over every detail until it was superbly immaculate. It was never about endlessly refining for the sake of it, and not about adding juice. Instead, I wanted the result on the whole to be solid enough to not be embarrassing. That’s what I really meant.

Reflecting on it from time to time, I’ve come to realize that I likely have a strong sensitivity to quality. I take a pragmatic, almost clinical approach to spending money. Before making a purchase, I create a mental checklist of criteria, and thoroughly research before allowing myself to get excited about it. Yet, sometimes even without knowing the brand or the price, I gravitate toward the higher-end options in a given category. It’s both blessing and curse, especially when I’m shopping offline, where I somehow always end up picking the most expensive items before checking the price tag.

On the one hand, I might just be naive and impressionable, not noticing how I’m getting sweet-talked by marketing. On the other, I like to believe it’s also having a keen eye for quality and paying close attention to the subtle details that signal care and craftsmanship.

It’s also what makes working in enterprise software frustrating for me, because not only is it a race to the bottom - achieving the set objectives as cheaply as possible - but, usually, nobody with enough control over the project appreciates it when you polish. Requirements change, polishing happens in places nobody cares about, polish can introduce things that slow down workflows, I’m painfully aware.

But what I realized over time is that, even working on my own projects with full creative control, I don’t polish immediately. What I actually do in the spur of the moment is not polishing, it’s sanding. When I’m forced to let go of things that aren’t sanded, that’s when I feel truly dissatisfied.

Sanding Everything

I really appreciate Jim Nielsen’s blog post on sanding UI (and part the second). In a very simple way it put a word to what I’ve been doing for years and years and made it tangible for me. As the saying goes, words mean things, and it doesn’t have to carry the baggage of polish.

While I think that creating user interfaces is a very good vehicle to exemplify sanding, I see it also taking place in all kinds of different spheres and ways. Because I like making many different things in the digital realm, I find myself confronted with sanding across many disciplines.

To me, sanding is an exercise in getting to know what the low hanging fruits and the acceptable quality bar in a certain discipline are, and interspersing my time working on something to find and implement little improvements - what Nielsen calls “feeling for splinters”. It spans across basically everything I find myself producing - software architecture, hard and soft surface 3D modelling and texturing, printed goods design, web development, level design, shader programming, music and sound mixing, and so on - often right from the conceptualizing phase.

Unsurprisingly, I’m not satisfied with my work when I have to painstakingly unravel the horrors of numerous thoughtless split-second decisions that led to interdependent permanent temporary band-aids. Sanding is no guarantee for that not happening, but it requires taking another look (and maybe a different look) at the thing in development, and that heightens the chance of catching missteps.

Sanding is simultaneously an improvement to the thing we’re creating, and an appreciation for what we have achieved so far. It requires and communicates to others that I truly understand what I’m making, and test-driving it myself while seeing it improve in rapid feedback cycles feels rewarding.

Sanding Is Thoughtful

There are a myriad of takes on why we make software, but for the purposes of this section, I’ll focus on software for the workplace.

Ideally, we make software to make life better - help people achieve something, reduce frustration, but at the very least to make line go up. Best-case scenario, work becomes easier, more fulfilling, and leads to happier people who are happy to be highly productive.

Slightly more realistically, to this end, work should be a little bit of fun. Maybe not so much as to detract from why we’re doing the work in the first place, or to distract us so much that we lose our focus, but enough fun to keep us engaged.

That’s why I never play the pissed off customer. I want good service, so I try to be as helpful and friendly as I possibly can, because I want people to do something for me. Making someone’s day worse rarely nets the best result if I’m depending on them. Their willingness to be engaged in our interaction will sink. Conversely, kindness often leads to fast, excellent service, and smiles all around.

This is one way in which much of enterprise software lacks. It generally treats users badly. I don’t lament that there’s no fun in it. It just completely lacks a sense for what’s engaging, and shows not the least bit of sympathy. Maybe it’s asking too much, because people ought to work more, not enjoy the process.

As a result, often enough, users have to deal with ridiculous situations: Nested remote desktops, torturous performance, confusing UIs that are direct representations of their complicated backing data structures, or that don’t communicate their state clearly (looking at you, Teams), stability issues, glacial maintenance. A cursory selection of the usual state of affairs in the typical workplace.

Sanding on its own can’t fix any of that, but it can make the experience more bearable at least, even if the rest is a flaming hellscape. It implies that at least a modicum of thought was spent on how a thing will be used.

Why I Sand Early

I determine the best time for and amount of sanding by trying to understand how technically experienced the one(s) judging the work is, and how central an individual aspect under consideration is to the whole experience. Let’s take software development for example and throw in game development for good measure.

Working as a freelancer and later for a software dev consultancy, I got the privilege to work with all kinds of different people from different lines of work, and wildly varying experience with software development. Some of these people are completely oblivious to how the sausage is made. The same is true for gamers. Somewhat less so for PC gamers than ones primarily on consoles or mobile platforms. But the fact of the matter is that everyone’s different, and everyone has different interests and priorities.

I like to account for that, so if at all possible, the amount of effort I put into sanding is somewhat inversely proportional to that experience level.

In Software

Project managers often insist that “the minimum working thing is more than enough”. But when it’s implemented precisely to that specification, they will often get caught up on details and be disappointed. Demanding improvements is totally fine, but unfortunately that all-important first impression is now soured. And, in the worst case, it will silently weigh on your reputation.

That’s why, when building UIs, I follow Nielsen’s advice - I constantly play around with what I’m making and I try to break it, finding and fixing small deficiencies. Most of the time, I do that as I’m implementing it. Regularly, the results go unnoticed because it “just works”, but sometimes it’s visible enough that clients are grateful for it.

An example came up recently. A feature to manage project avatar images was deprioritized mid-implementation, and the sidebar where those projects could be switched between looked absolutely dreadful as a result, because it had no avatar fallbacks in place. I avoided showing projects without avatars in demos until we finally tackled the issue.

The fix was planned to display a plain background and a generic icon - the simplest possible version of a fallback. Suspecting it to stick if I let it, I decided to ignore the requirements that time.

I took the extra time to implement an algorithm to generate stable, colorful, and contrasty fore- and background colors based on project names. It would spit out enough different combinations that even having the whole sidebar populated, the avatars were distinct enough for it all to be easily distinguishable. I also made it generate its colors in the oklch notation, so the avatars would pop on wide-gamut displays (in moderation), and ensure enough contrast, making use of its consistent lightness property. The two or three letters derived from the project name would scale to fit inside the avatar with a consistent padding for visual cohesion. It made the rest of the quite enterprisey and boring interface a lot nicer looking.

The PO was stunned by how the austere UI suddenly came to life when I showed him. He didn’t mind the extra time taken at all.

I was later told that users were tempted to have the sidebar chock-full with projects, just to make their workspace more engaging. The avatar fallback took me half a day to implement, and the other half to sand and test. A small detail in the grand scheme of things, but it added just that little bit of playfulness and fun.

It was of course also a case of giving a shit or not. But what isn’t, really.

In Games

I observe the same thing in games.

Game development is a very complex and highly multi-disciplinary thing. To put it in a way that doesn’t do it justice, the complexity mostly comes from cohesion being very important for a gaming experience as a whole to feel well-made, and from designing the thing so it steers emotions in a way that is desirable. There’s just so much stuff that has to intertwine in the right ways (see the Door Problem for a glimpse) for it to not be off-putting.

When working on games, I like to lead with getting the atmosphere dialed in, and letting much of the rest fall into place from there, because getting the atmosphere right requires that cohesion on multiple parts of the production. That’s easier said than done though, because for it to not be a jumbled mess of loosely fitting parts, it requires trying to form an all-encompassing vision of what something will be like to experience. The art direction, a potential story beat, the resolution of the volumetric fog, the ad hoc emotion players should experience, the thoughts they should have if they were to deeply engage with it in that moment, the footstep sound for damp carpet #6, the voice of our silent protagonist, the room tone-like droning music, the shape and color of light sources, the backstory of our goofy comedic relief character. The list goes on.

I really hammer that vision into my brain and do my best to keep the memory fresh for as long as I take to make it happen. It’s like a target clip that I have in mind, enriched with the technicalities that would come up when implementing it.

Play

Play

Like any other software, games go through stages of development, and the first couple level block outs and gameplay prototypes are usually the point where we try to judge the interplay of it all, to understand whether it’s valuable enough to make in earnest. And usually, neither testers nor stakeholders, or even developers are able to withstand early-stage jank skewing their perception:

They all say they are good at looking past the gray boxes, the bugs, the crashes, the ear flicks. But then they are grateful when a buggy playtest ends, or grateful when the whole playtest is cancelled, because it is a painful experience.

— Greg Street for Polygon (Source)

And it is painful for different reasons. Testers may say they didn’t like the gameplay when in reality they’d have a kick-ass time with the final art assets and lighting in place. Stakeholders and owners might have second thoughts about their investments into this buggy mess, when it’s just the character controller getting stuck on slopes because its maximum climbing angle isn’t configured correctly.

One is vastly, vastly more elaborate to fix, with hundreds of layers of sanding and polish involved - years into the future probably. The other is maybe a couple of hours of sanding if we discount external playtesting.

Developers should have the best chance to see past it all, but I’ve experienced firsthand teams that pushed MVP-thinking in the same way I outlined previously. When we didn’t have time to sand, it made internal playtests disappointing, showing off the thing to others embarrassing, and nobody involved could precisely pinpoint why exactly. Well duh, because it wasn’t quite good enough! But looking at a jumbled mess that’s already happened and determining what tiny improvements will magically open the pearly gates is way more painful than sanding.

While the concept was great as it was in my mind, A Breathtaking Flight was bogged down by its scope because of deadlines that were breathing down our necks the entire way, which made us forego sanding completely. Through sheer will, working ourselves to the bone, and not having a ton of fun, we nevertheless forced it to work, but it was far from refined. It was functioning, and showed the concept’s potential, so it achieved its goal. But as I wrote in the case study, if the whole thing was to be made for real, we would’ve had to throw it all out and start fresh.

For my personal projects before that, and for Fey: Distant Daydream, I’ve embraced more early sanding, where I get closer to the target I set in my mind, work on the little things some more, have it in a more presentable state early, so that everyone has an easier time to grasp the vision and believe in it. It usually yields a lasting boost to morale.

Conclusion

Sanding everything and sanding early isn’t the one and only solution, but it helps if you can somehow squeeze it into the alloted time budget. It makes working on things more fun, doesn’t have to cost a lot of time, but you require experience to judge when and where sanding time is best spent.

While people try to get away with proofs of concept as much as possible, they aren’t oblivious to recognizing quality. They usually notice and appreciate when something is made with care. And that is often enough the sum of all kinds of little thoughtful improvements made along the way.

One of the things I often get flak for is that I love giving new projects a pretty name and making a logo for them. To me, it makes the endeavour feel more official, and not like some kind of grassroots backyard operation. It’s probably one of the more superfluous ways of adding to a project, but it nevertheless motivates me. And later, when it comes to presenting the thing to outsiders, people are excited that we have a catchy name and a logo to make fancy presentations with.

Because of the double-standard that people are hell-bent on making MVPs to go as fast and cheap as possible, but at the same time are openly grateful for things not being subpar, I believe sanding and being smart about it is a good skill to have.

Happier people do better work. And that’s true for everyone.

Thanks again to Jim Nielsen for his blog post!