Development blog with annotations, links, images and anything I find interesting.

Specs vs Common Sense

So I was browsing through reddit and came across this picture:


source: reddit

Apparently the kid did not follow the specific method the teacher has taught the class during the past weeks, presumably he wants the students to have a huge loathing against commutative addition or to common sense, or even worse: creative and different thinking.

I’m not writing a post against any educational system, I mean the kid got a D with no wrong answers, that’s pretty unfair. But I’m not an expert in that field, or actually any field to begin with. What really got my attention were the comments that followed this post in reddit by Evilsqirrel :

I actually just recently ran into an issue with my programming course where they knocked off 10 points because my output was 1 cent off what their "desired" output was, regardless of the fact that my program was actually rounding properly instead of truncating, making it more accurate than it actually was. I never hated a teacher so much in my life.

To which somebody named qwertyslayer replied:

I’ve got bad, bad news for you if you want to be a software engineer that works for money.

He can’t be more right! I’ve gone through similar situations during my career, in many projects and in very different scales. What I’ve really learned is that you have to choose your battles, you’re paid for your expertise and for your skills, my problem is that I have amazing skills to detect this kind of problems (The client wants something that will eventually lead you and him to hours of frustration and bug hunting due to bad approaches and rules that don’t follow common sense), my advantage is that I have good ways to work this through by communication and negotiation (Sometimes the client really wants that feature that will shut his business down and it will be extremely hard to convince him otherwise).

So what do I recommend: don’t be an asshole. When some points in the specs doesn’t follow common sense or has some technical underlying issue → Go and talk about it with your client/boss since it will free you from the suffering caused by taking one of the 2 potentially wrong decisions: 1. You fix it and keep your mouth shut, then it will explode in your face when he tells you that it was primordial for the product. You fix it back, it explodes on his face and then you find a 3rd solution that was the ideal one to begin with. 2. You do it just as it’s detailed in the specifications and then it explodes in your client’s face, the client loses money/time/users and you simply say 'it was written here' and I said nothing about it because I didn’t have to.

Anyways, you can also have the case of having specs that do not make sense (or common sense) in many areas (disorganized, contradictions, etc). In such cases it’s always good, in my opinion, to start your own documentation stack, or your own specification in a better format and language. For these cases I’ve recently found that the specification for XHTTP that my colleague @jameswatts wrote is really well outlined and it’s a nice starting point:

What was the nicest decision the kid should’ve made that day during that exam? Probably the one he took, he went ahead and found a solution for a problem that was given to him. Probably his parents will pay a visit to the school and hopefully this teacher stops killing kid’s motivation to learn and specially learn math.

For a final statement I will leave here another comment from the thread by ituralde_ that really rounds things up with this topic by explaining a real life example of how common sense might not make your life easier all the time:

Hey, former dev at a bank here.

Being "better" isn’t strictly right. This isn’t just your professor being an asshole, I was on an actual project that had pretty much this exact same problem.

Project involved effectively automating some collateral value calculations. We were given a spreadsheet with some sample values and were given the maths and were told to match output. We didn’t bother to check that the formatting rules truncated at certain point (at the millions). We get into UAT and the business test team throws a fit because their numbers aren’t matching up. 6 hours of stepping through the math process starting at 3 am before we figured out that having "wrong" (truncated) numbers was an important aspect of something negotiated in the contract underlying this particular calculation. In other words, even though it represented (across the full range of clients for this tool) a multi-million dollar disadvantage, we were still supposed to directly do it wrong.

TL:DR it’s not just your professor, sometimes it’s your job to do it specifically wrong