This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: Software Talk -> English
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
Us in the software industry have certain phrases, and even stories, we like to use when talking about our work or responding to customers. If you're up on your Godin (All Marketers Are Liars), it's something along the lines of the "vernacular" we use to tell our stories, hang our "frames," etc.
We ourselves don't usually encounter or think about the silliness of these phrases unless other software people use them on us. In which case we think, "oh, I know what that means...'cause it's something I'd tell someone as well."
Here's a couple:
"That should work" - whenever should is used, it means, "I have no proof that X works, and I didn't/won't spend the time to find out. I might consider fixing it if you try it and it doesn't work. But probably not." As in, "using the XML export from MS-Word to import to Open Office should work."
"You're the first person to ask for that feature." - As an end-user, you might ask the creator of the software to add in a feature. When you get this response, it means "we're not going to add that feature...unless you give us lots of money."
"The [feature|bug|software change] makes sense to me." - If you talk to someone and suggest a change to software, they might give you this response. What this means is, "I have no power to influence the features of the software. You might as well not even be talking to me."
"Why are you doing that? You should be doing this other thing instead." - You can't figure out how to do something you want to do with the software. When you asked the software people how to do that something, they immediately give you this response, which translates as, "our software doesn't allow you to do that, and you're not valuable enough to us such that we'll make it do that. Instead, we're going to (try to) convince you that you shouldn't want to do that...so we can avoid having to write the code to make it possible."
"The work-around is..." - When you encounter a bug, you're often told how to go about doing things to avoid the bug. What this really means is "your don't pay us enough money for us to go and fix this right now and send you a patch."
As you probably noticed, all of these have to do with avoiding doing work that a customer asks for. Interesting that, isn't it? If you're familiar with software development cannon, that's pretty much the prime motivation for anything: do as little work as possible, either by (a.) shaking off as much responsibility to decide what to implement (Agile) or, (b.) avoiding writing more code than originally planned for (waterfall).