Reflections

softwaredevelopment

Managers and organizations want to know exactly when features, bug fixes, and other work will be done. Many have not been software engineers themselves, so they ask for exact dates. Sure, you can be off by a day or two—maybe!—but more than that, and it's a problem. After all, their boss needs to know what to promise customers. What's so hard about knowing when you'll be done?

Sadly, software cannot be estimated that way, and we need to stop pretending otherwise. It's a myth—a pervasive one—and perpetuating that myth only perpetuates its harm.

An illustration of a man with an unhappy expression looking at a piece of paper in a physically impossible maze inspired by M. C. Escher's artwork. In the background, a woman can be seen navigating the maze, confused.
Image by ChatGPT

Sure, if a task is almost identical to some previous task, a precise and reliable estimate really can be communicated. Unfortunately, that almost never happens. If the work ahead were so similar, someone would have done it already using copy and paste. If it's similar and the engineering team wanted to set themselves up for success later, they'd refactor the system. That refactoring itself can be a hazy fog of unknowns. We've all been there many times.

In my fifteen years as a software engineer, I've worked in many different kinds of organizations, from a small non-profit research and development lab (the Open Publishing Lab at RIT), to a medium-sized, quasi-non-profit business with a deep and pervasive developer culture (the Mozilla Corporation), to a for-profit startup in the music industry (Inveniem), to a publicly-traded conglomerate with an estimated 100,000 employees (Honeywell). Although I have fond memories with all of my former employers, in my experience, not one was even remotely better or worse than any other at software estimation. Clearly, something more fundamental is wrong. I think the problem is obvious. They all wanted to know the unknowable.

Read more...

I'm a Woz, not a Jobs. I write this in reference to the personalities of Steve Wozniak and Steve Jobs, the founders of Apple, although I would never claim to be as intelligent or as effective as either of them. Although I do have a strong product mindset and deep interests in usability and user experience, at the end of the day, like Wozniak, I want to be a good programmer, not a good businessman. I want to learn, not earn.

Some people are motivated by money, and that's completely reasonable. It pays the bills! It's just not who I am. It's not who I've ever been. Money, metrics, status: I care about those things like penguins care about Pilates. I'd rather watch paint dry.

Don't get me wrong. I can be deeply motivated under the right circumstances. You can hardly pull me away from the computer when I'm learning, iterating, honing my craft, and producing something I'm proud of. That's where I find flow. “Faster, faster, faster, more, more, more!” just because that’s what your boss wants? No, that doesn't work on me.

I'm amazed that style of management works on anyone, to be honest, but it must. I suppose some people who are motivated by promotions and prestige can clench their teeth and bear it. Maybe they even enjoy the challenge. Me? I don't see the point. Life is short, and nobody spends their final moments reminiscing about their corner office or their fancy car. Let's be honest, those things lost their luster after one week.

I regret not being more clear about this aspect of my personality in the past. Moving forward, I want to embrace who I am. If others don't like it, that's fine, but they're probably not the right people for me, and I'm probably not the right person for them.

#Favorites #Life #Maxims #SoftwareDevelopment #Tech

The other day, I watched as a customer walked into a restaurant asking for his order. The restaurant hadn't received the order, however, and the man became upset. He admitted that he's not great with technology, and he complained that this always seems to happen with the restaurant's third-party ordering system. When it does happen, he gets no confirmation email and his card is not charged.

The next day, someone in an online class expressed confusion about how to meet their coach for a scheduled appointment, but the coach had no appointment on their calendar. Similarly, years earlier, a relative told me they had ordered an Uber, but it never showed up.

In all of these cases, I'm almost certain the users did not click the final button labeled Order, Confirm, Submit, or similar. (The restaurant owner blamed browser cookies, but that has nothing to do with it.)

I can hardly blame these users, though. I once showed up to a hotel, thinking I had booked a room with them, only to find that they had no reservation under my name. I looked for the confirmation email, and sure enough, it didn't exist! I needed to quickly book with some rinky-dink place across the street. I had made the same mistake!

This isn't about tech literacy or intelligence; it's about bad user interface design. A depressing amount of software ignores the basic rules of usable design. In this case, what looks like a confirmation screen (i.e., “your order has been placed”) may actually be a confirm screen (i.e., “tell us that you're sure”). When users are on those screens, their loci of attention may be on the order details rather than the user interface. They want to know that the flight time is correct. They want to know that the price is correct. They may not be paying attention to the Confirm button, which is probably offscreen anyway. They may not be looking at the tiny text at the top which reads, “Please review this information before booking your flight.” They are focused on something else, which may explain why they miss context clues in the periphery. Jef Raskin discusses this at length in his book, The Humane Interface.

So before leaving an app, website, or other ordering system, be sure to confirm, confirm, and confirm again. Slow down. Read carefully. Scroll. Zoom in and out. Make sure there's nothing else you need to do. A few seconds of prudence may prevent lots of frustration later.

#Life #SoftwareDevelopment #Tech #TechTips

This fairly recent obsession with metrics in the workplace is driving companies insane.

A while back, I watched a video about all the ways hotels are trying to save money by, among other things, eliminating storage space, making the bathroom less private, removing desks, and pressuring guests to work at the bar, where they can spend more money. (By the way, that bartender? They're also the receptionist.) These changes are, of course, driven by metrics like “GSS” and “ITR,” whatever the f@*k those are.

Is there a kernel of truth to all of this? Sure. Aloft Hotels are cozy, and they seem to follow this playbook. I didn't mind staying in one when I was stuck in San Francisco for one night more than ten years ago. Would I want to stay in one of their rooms during a business trip or anything else lasting more than a couple of days? Hell no. I'd like a desk and somewhere to put my clothes. (I know, I'm so needy. I travel with clothes.)

Metrics are fine, sometimes, when their use is limited and their shortcomings are genuinely appreciated. Taking them too seriously and letting them make the decisions, however, is a recipe for disaster. Hard questions demand more thoughtfulness than that. “GSS” and “ITR” are meaningful until they aren't, and nobody is going to find solace in those abbreviations when generations of potential customers steer clear of your business because they actually want something good.

Sadly, I don't think most businesses think that far ahead.

Show me the metric which proves that your business isn't taking a massive risk by ignoring common sense. Until then, I don't care about “the numbers.”

#Life #SoftwareDevelopment #Tech

Distrobox is amazing. It's like Linux Subsystem for Linux in the best possible way. (That's a play on the name Windows Subsystem for Linux.) With one command, anyone can spin up the shell environment of another Linux distribution, and the host files will be right there. Are you using Debian because you value desktop stability, but you want to use the latest Neovim? No problem. Use Distrobox to create an Arch or Fedora environment, install Neovim, and use it. That's it!

I'm surprised, disappointed, and a bit embarrassed I didn't know about it until now.

#SoftwareDevelopment #Tech

Progress bars—those little horizontal bars that fill from left to right as your laptop or phone updates—are notoriously unreliable. One moment, a progress bar might be 10% full. The next thing you know, the work is done. If a written estimate is provided (e.g., “10 minutes”), you might notice it change dramatically in an instant.

As it turns out, building accurate progress bars is extremely difficult. In most cases, it's almost impossible for the computer to know how long the work will take without actually doing it.

This is the problem of software project estimation in microcosm.

#Favorites #Maxims #SoftwareDevelopment #Tech

Liquid Glass is bad for cybersecurity. Millions of people have learned the hard way never to update their devices, because if they do, everything might change for the worse. Of course, this isn't the first software update to annoy users with seemingly pointless changes, but it may be the worst case of it.

#SoftwareDevelopment #Tech

Remember, if you don't pursue your own stupid idea, you'll end up pursuing someone else's stupid idea. Case in point: Liquid Glass. Someone at the top thought it was a good idea, and thousands of Apple employees were apparently too afraid to say, “This sucks.”

#Life #SoftwareDevelopment #Tech

I was recently listening to a podcast about the Branch Davidian cult, led by David Koresh, and how the FBI attempted to end the standoff by, among other things, flooding bedrooms with light to prevent sleep and blaring the screams of dying rabbits over loudspeakers to drive the Branch Davidians insane and hasten their surrender. Apparently, someone thought this was a good idea, and apparently, no one was brave enough to tell that person they were wrong.

The lesson? Speak up. Trust yourself. If you don't pursue your own stupid idea, you'll end up pursuing someone else's stupid idea, and the latter will often be much, much more stupid.

#Life #Maxims #SoftwareDevelopment #Tech

About two years ago, I wrote that the Beatles never set OKRs. It was the punchline to a larger point, but at the time, I was working for a company in the music industry, and I didn't want to criticize music manager types.

Now that I've moved on from that company, and especially because my car sports a custom bumper sticker with the phrase, I've decided to share the unabridged version:

I tend to believe that working too hard to come up with a name for a brand or product is pointless. A name doesn't need to be good to stick. I could point to Facebook or Apple, but there may be no better example than The Beatles. It really is a strange name. It's a pun! It's a dad joke! And yet, I can't imagine them being called anything else.

Can you imagine what a committee would have named the band? For that matter, can you imagine The Beatles writing roadmaps and setting OKRs? Sheesh.

Now that's a t-shirt. “The Beatles never set OKRs.”

I obviously feel the same way today. Speaking of music, maybe that's why one of my favorite Pink Floyd songs, both lyrically and musically, is “Have a Cigar”. A lot of management—certainly not all, but certainly too much—is worse than pointless. It's actively harmful.

#Life #Maxims #SoftwareDevelopment #Tech