The other side of “Just”

Another perspective on the most dangerous word in software development.

A little over a year ago, A List Apart published an article entitled “The Most Dangerous Word In Software Development” and I thought (aside my distaste for title case in post titles) that it missed an important aspect of the word “Just”.

There’s the side that says “Just put it on server x” or “Just use a closure” or even “Just register a callback to the controller in the router”, but there’s also the side that says “I just want a site that does x” and it’s this perspective that I’m ranting about exploring here.

Just do x!

The problem with “Just”, as rightly stated by the article linked above, is that is makes loads of assumptions about what people know and about the consequences of the proposed action.

“Just” makes me feel like an idiot. “Just” presumes I come from a specific background, studied certain courses in university, am fluent in certain technologies, and have read all the right books, articles, and resources.

Anthony Colangelo

For someone who, for better or worse, has access to production servers, that makes me very nervous. If I said “Just put a codebase no-one’s familiar with on the same server as our corporate website and just go ahead and install whatever dependencies you need and just use the shared database instance” you’d think I’d gone mad, but a dismissive “Just put it on hostname x” is just equally as bad.

I just want a site like Facebook

The kind of assumptions I’m talking about here are different from Colangelo’s in that they apply specifically to new shiney things that people who can’t make shiney things want so they get people who can make shiney things to make shiney things for them. It’s touched upon briefly here:

“Just” implies that all of the thinking behind a feature or system has been done

But it’s more than that. And not just in a “aren’t non-technical people funny with their View Source and I-want-to-build-the-new-facebook” way but in a subtler, more sinister way: assumptions trickle down from management to those in the pits. It starts with something innocuous like this monstrosity of a project I totally made-up but could probably get away with saying I found on elance if I were so inclined:

I just want a site like Facebook and with video like YouTube but it’s a membership site so people have to pay and they can sign-up to events that recur every fortnight of every even month (except April!) and it has ads and people can register for email addresses and feature x and feature y ad infinitum

Ok, that was a bit silly. How about:

I just want my blog to say “Good Morning!” or “Good Afternoon!”

Simple enough, right?

Trickling assumptions

The problem with assumptions in software development is that someone will inevitably have to make a decision — the beauty of it is that the person making the assumption assumes no responsibility for it.

Even in the contrived example above, we’re assuming quite a bit, or rather, we’re actively ignoring the extraneous factors that will define how a feature will behave:

  • Which timezone should the system check? UTC? Server time? User’s timezone?
  • Should it be on every page? What about the login page? What about the full-width landing pages?
  • What about “Good Evening!” or “Good Night!”? They both sound like farewells, but saying “Good Afternoon!” at 2200hrs just doesn’t feel natural

These assumptions have tricked-down from the person who wants a sickeningly-chirpy greeting on his site to the poor dev who has to waste an hour on this pointless feature. Now, I know what you’re thinking: why doesn’t he just ask these questions to find out the desired behaviour? In this contrived example, sure, you could just ask, but in the “real world” (or IRL, as I read on voat recently and assume is still a socially-acceptable initialism) nothing is ever that simple.

Software has finer points, like whether a dropzone should be as big as the dragged object even when it’s massive, or whether our webfont should fall-back to Arial or Helvetica first and these decisions have consequences. You wouldn’t say “just stick the aerial to the wall” or “just put 256 inch wheels on my fiesta” (I know nothing about cars) because your cable may not be long enough to reach the wall the aerial gets attached to and your pimpmobile may not have…arches?…(I think)…big enough to accommodate tractor tyres.

What if your wheels are only 8-bit unsigned integers and can’t store numbers that large?!

Return on investment

The final side of “Just” is the question “What’s the point?”. Often, the-word-I’m-sick-of-typing is used in a request for a feature that may well take more time and resources than it’s worth and if it’s impractical to define the feature in its entirety (e.g. “just a facebook clone”) then chances are that much of the feature set isn’t integral to the purpose of the project in a MVP kind of way.

Sure, you could spend (just!) 6 hours making the perfect module for greeting users when they login, but is it worth it?

The takeaway

28 “Just”s later, I suppose the takeaway is to be mindful of our assumptions, especially when we’re describing something that’s far more complex that is practical to fully explain. Like software. Or cars, evidently.

Leave a Reply

Your email address will not be published.