“Just put it up on a server somewhere.”
“Just add a favorite button to the right side of the item.”
“Just add [insert complex option here] to the settings screen.”
Usage of the word “just” points to a lot of assumptions being made. A few months ago, Brad Frost shared some thoughts on how the word applies to knowledge.
“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.
He points out that learning is never as easy as it is made to seem, and he’s right. But there is a direct correlation between the amount of knowledge you’ve acquired and the danger of the word “just.” The more you know, the bigger the problems you solve, and the bigger the assumptions are that are hiding behind the word.
Take the comment, “Just put it up on a server somewhere.” How many times have we heard that? But taking a side project running locally and deploying it on real servers requires time, money, and hard work. Some tiny piece of software somewhere will probably be the wrong version, and will need to be addressed. The system built locally probably isn’t built to scale perfectly.
“Just” implies that all of the thinking behind a feature or system has been done. Even worse, it implies that all of the decisions that will have to be made in the course of development have already been discovered—and that’s never the case.
Things change when something moves from concept to reality. As Dave Wiskus said on a recent episode of Debug, “everything changes when fingers hit glass.”
The favorite button may look fine on the right side, visually, but it might be in a really tough spot to touch. What about when favoriting isn’t the only action to be taken? What happens to the favorite button then?
Even once favoriting is built and in testing, it should be put through its paces again. In use, does favoriting provide enough value to warrant is existence? After all, “once that feature’s out there, you’re stuck with it.”
When you hear the word “just” being thrown around, dig deep into that statement and find all of the assumptions made within it. Zoom out and think slow.
Your product lives and dies by the decisions discovered between ideation and creation, so don’t just put it up on a server somewhere.
One of our values here is to “interrogate the premise”. This applies to design solutions and tech solutions alike. If your project is moving so fast and so carelessly that decision-makers aren’t accountable for the depth of the stuff their team is “just” doing, they’re probably sitting on a huge pile of risk factors that could blow at any time.
I’ve been trying to get “just” out of my vocabulary for months and months and months now. it sounds so dismissive in almost every instance. ‘that person is “just” a [insert job title here].’ or ‘it’s “just” a draft.’ or ‘this set of unlucky/tragic circumstances is “just” how it goes.’ the modifier there can pretty much always be unpacked.
“Just” is only one of the four letter words to be careful with:
https://signalvnoise.com/posts/439-four-letter-words
“Just” is worse, “In my experience” is worser and “The reality is” is worst.
Ex. The mobile Facebook Messenger button on Android is really vexing. Persists and Gets in the way of everything.
Touche, Anthony
When it comes to software, “the devil is in the detail” is almost always applicable. As developers, we should always keep this in mind and also “educate” clients and stakeholders about this. Thanks for pointing it out. Cheers.
“Just” implies that something is Easy, and often begs the question of whether or not the speaker intends to pay for such work, since it’s so easy.
It’s like telling Frodo “Just take the ring to Mordor and through it in the volcano. That’s it. World saved.”
This discussion can expand far beyond the world of software development. I work as an interaction designer and when I’m having a discussion with business partners or clients, I automatically cringe when someone starts a sentence with “Can’t we just…?” or “Let’s just…” It implies a lack of knowledge about what is being asked, as well as a lack of care, which I find to be even worse. It’s one of the most flippant and dismissive (as Amelia C. noted above) terms I’ve ever had the displeasure of hearing in a meeting.
It seems like “just” goes hand-in-hand with “while you’re in there”. I know this isn’t part of your task, but while you’re in there why don’t you just fix bug 1234? Now we’ve added scope creep and an assumption that something is easy.
“If you could just go ahead and do that. It would be greeeat…”
– Office Space
I see your point, ‘Just’ is bad. The worst word in this business is ‘Magic’. ‘Magic’ is the word used by idiots who do not know what they are talking about. Usually these idiots are so-called project managers but often it is other so-called developers. ‘How does Mongodb handle polymorphic document storage, its magic!’, ‘How will we somehow pull together values from a normalized data schema and display it on a web page in human readable format, magic!’, ‘I need you to perform some magic so the customer doesn’t fire me for being such a sloppy performer.’
Some of us took the time to learn these things so we could apply scientific techniques to our labors. Give us the nod for being smart instead of conjuring up Moloch and giving him the credit.
“Just add a button”
“You got it boss!” Thumbs up.
“That guy has a good attitude..we need to keep him”
Actually the most dangerous word in SW design is “Test”. While its meaning has morphed to include review, testing in software uses a huge fraction of the development schedule and budget but returns very little in benefits. It is like a mill stone around our necks that we refuse to take off. Some testing is obviously required but testing to find defects is a colossal waist of money and time, particularly testing at the system level. In his book, “The Art of Software Testing”, Myers compared the defect load to an iceberg. The tip of the iceberg is all we can see while 90% is hidden. Similarly, with testing we can only find a fraction of the defects while most of them are hidden. The bigger the iceberg, the bigger the visible part. The more defects we find, the more are left undiscovered (assuming a similar level of effort).
The second most dangerous word is “Feature”. Features are what users see, not what software developers produce. Developers produce code modules that, when cooperating correctly, provide the features the customers need. Assigning a feature to a developer or a small development team gives them cart blanch to wander through any of the code and screw up things that they do not understand. It is easy for management but not good for product reliability.
Kisses
Irene
I believe being told “just do it” by a stakeholder signifies disinterest, not trust. And it is risky when that stakeholder distances him/herself from the issue at hand.
Don’t mistake it for implied “trust”.
I have been pleading with with my team for years. Thank you for putting my sentiments toward the word “just” so eloquently.
It’s never the case because “just” means the opposite of the above. In the examples given I would take it as: “do this for now until we have time to do the required thinking behind it.”
“Just” can be a dangerous word – as “that’ll do for now” – but your interpreting it as “we’re ready to” is surely more dangerous.
So it turns out that the most dangerous word in software development isn’t “deadline”. What a relief.
Actually, when I hear any of three software development swear words, “all”, “only”, or “just”, I am reminded of the infamous iceberg analogy. The person swearing is seeing only the tip of the iceberg that has pierced the surface while the entire mass of the work to be performed lies beneath. They assume that this work will be done “somehow” but they do not have the knowledge or experience to tell how much work is involved or how long it will take. I carry around three index cards with one of the swear words on each. Every time the client utters one, I simply place the appropriate card on the table. Afterwards, I explain to my client as delicately as possible the entire scope of the work and I use the iceberg analogy. This usually is sufficient to have the client begin to understand a bit more how the software development process works and their role in it. Their role is to describe the tip of the iceberg as they see it. I explain that it is now my job to make sure that there is sufficient structure beneath to hold their desired functionality above water. If this does not work, I try another explanation with more detail. If it still doesn’t work, I thank the prospective client for their time and simply walk away.
Nobody gets hurt and they can find themselves another consultant, whoever that poor sucker may be! 🙂
I saw this gif on reddit that perfectly sums it up: Programming in a nutshell http://i.minus.com/i7zx1W08sXciX.gif
“How hard would it be to….”
One I hear allot.
I love the functionality of this site. It really just flows awesomely. Nice article too, I found it to be deeply motivating. I’m just starting out, and I appreciate any feedback
Probably the best thing you have seen all day.
amelia c: Just stop saying it 😉
All others: I would like to know the official Nike position on this article.
Just is a multi-loaded term ( sometimes called an over loaded term ) it can mean ‘recent in time’ or ‘legally good’ so this article is a little ambiguous and need more formal data definitions before being called into practice. For example
Bob: “How’s the new app?” Susan: “Just put it on a server somewhere” same sentence, different use case.
So the outright probation of the 4 letter tag “just” should be well thought out.
… I’m just saying…………you know ……. 😉
Just is also a useful limiting term: Just a minute, Just a drop, Just a server.
But that points out that just is not a Commutative term as
“Just a server” is not the same as “A just server”
Nope Just is not the most dangerous word in software development.
‘Do’ is.
It will DO…
Do you think..
I can DO
DO i=1 to -1 by 1
That will DO pig, that will do.
I’m sorry, this is a valid JUST… You should not be developing in a way that is so far off the rails of how your organization would actually host an app. With The Cloud, just putting it on the server should be an exercise measured in minutes, whether it’s 25, 100, or 200. It should not be an exercise measured in days.
You don’t launch a scalable production grade system by “just putting it up on a server somewhere”. No (competent) business person would ever tell you to launch a flagship product in a single sentence like this. Using your exact words ‘side project’, the phrase “just put it up on a server somewhere” should be the most desired sentence to hear!
Nice read. Somewhat comforting.
I was once asked to “just put a search field here”.
Go figure…
Or it implies that there is no need to think at all
Definitely something I’ve come across a lot, specifically related to feature requests from non technical managers. It’s harder to highlight to these people that what might appear to be a simple 5 minute job can grow into so much more.
Designing the obvious is a great book that talks about the problems with ‘just’ adding new features, when they appear to be simple and easy to do, its a dangerous game. ‘Just’ another small feature will create ‘just’ another feature to design, to test, to configure, to learn about and to conflict with something else. I always try and make a feature work incredibly hard to justify it’s place in a web application.
Just word can be just dangerous! Beware..
The word “Just” is only useful when you have nothing else to say, so it’s just meaningless… It’s like saying “no problem” to your customer, not pretty good.
Yeah, You are right about that because when we complete the project, then the mail come with lot’s of just and the project extent for more days.
Custom Software Development company
I think, The most dangerous word is ……
“I DID It.. But don’t know how….”
Wao excellent Article i like it very much because article consist huge information. I really appreciate on your great effort.