DEV Community

Cover image for What my bathroom window taught me about code quality

What my bathroom window taught me about code quality

Angelika Tyborska on August 06, 2017

This post was initially published on my blog. When my boyfriend moved into our current apartment, he realized there is a small flaw in the bathroo...
Collapse
 
dmakovec profile image
Dan Makovec

An interesting article! Excuse my rambling and tangential line of thought (it's my Monday morning train commute so I have time), but I have to admit, the first pattern I thought of when I read this is YAGNI - you ain't gonna need it. Risk analysis: while it's popular to think that everybody wants to see your business, more likely than not they don't care. Let's assume for a moment they did care. Well, the half frosting ensures all apartments below or inline aren't going to see anything. More likely than not anybody who can see anything will be at least two floors up, in which case anything they do see will be indistinct enough to be of negligible concern. That's assuming they even happen to be looking in your window at the time somebody is in there.

So the only people you're defending against are those who are pervy to be staring at your window, at the exact time you're in there, living directly opposite you, at least two floors up, with some sort of zoom lens.

So let's say you encounter such a person. What damage can they do? Chances are they don't know you. If they did see your bottom bits, then bring up so high they probably wouldn't see your face anyway. But suppose I'm wrong there; for them to do any damage they'd have to go to the lengths of establishing your identity, and then what damage would they do? Extort you for money or threaten to send photos to the papers of someone having a shower? Of course I'm being a little bit facetious here, as everybody's risk tolerance is different.

So that's when I go back to YAGNI. Every day when building systems, we assess risks, the expense of realising those risks and the expense of mitigating them. Sometimes the cheap hack is worth the effort. Sometimes though it's simply not with the hassle of doing anything.

Collapse
 
atyborska93 profile image
Angelika Tyborska

I loved your reply 😄. I totally agree about the very low risk of being seen in a bathroom. I guess my main argument for covering a window is not that I want to protect myself, but rather protect my more sensitive neighbors from accidentally seeing something they might find uncomfortable.

I am not very experienced. I find assessing risks to be a very tricky task. You simply need to experience a few system in your career to know there a certain situation might be going. I guess my mistake at the beginning of my career was assuming everything is important and high risk. It's not the worst of mistakes to make, but it caused me to slow down or even block certain features from being developed ☹️.

Collapse
 
mkuegi profile image
Markus Zancolò

This is perfect. I totally agree with the YAGNI from the "developer" point of view (in this case her). But there is someone else who can demand features/code, sometimes the tech lead, reviewer, even business (if its a feature). So YAGNI from her point of view, but he demanded to do something, therefore there was a need and it got solved with the least possible cost.

In this case a "better" solution (possibilities mentioned in the post) would be totally YAGNI cause noone needs it. Until a there comes a new boyfriend which is an interior designer :D

Collapse
 
slmyers profile image
Steven Myers

Maybe leave a word of warning in a comment?

I would rather the dev encapsulate the hack in a function with a indicative name,

function myDirtyHack(...args) {...}

Collapse
 
atyborska93 profile image
Angelika Tyborska

Great idea! I should use the next time I have such a need.

Collapse
 
pratikaambani profile image
Pratik Ambani

Nice article!!

5 more points for this line:
good software developer is not somebody who delivers good, clean code all the time, but somebody that is able to assess the situation and deliver a solution with the highest ratio of value to (long-term) cost.

Collapse
 
damcosset profile image
Damien Cosset

I loved how you compared your window issue with code related problems. Very well written.

Adds a few 'I was yound and I needed the money' in the codebase

Collapse
 
moopet profile image
Ben Sinclair

My thoughts on extending the metaphor:

There is a very high probability that in the future you will sell or otherwise pass on the apartment to someone else, at which point you will have become so accustomed to the cardboard that you don't even notice it anymore. Either they will ask you about it or they will assume it's because of something worse, like it's covering up a broken window and come winter there will be a lot of damp around.

If YAGNI and you don't bother covering the window, should you feel it's your responsibility to point out the flaw in the apartment to then next occupiers or will you assume that they're smart enough, observant enough and have enough free time to notice it themselves?

If you were applying for a job in construction, would you feel comfortable using this as an example of how you'd overcome a problem?

I'm not thinking of any particular answers, just adding bits :)

Collapse
 
kr428 profile image
Kristian R.

Loved reading your post and really found an earlier me on both sides of the fence - both complaining about others writing "bad" code and writing "bad" code (bad in another way) myself.

Code that seems to superficially patch away a certain problem that might require a deeper analysis and more thorough fix is bad in my opinion (in early versions of our application we had plenty of "if customer = ... then ... else ..." code segments to implement specific behaviour for specific customers which is obviously a bad idea). However, trying to make code clean, DRY, ... at any cost might end up in "bad" code, too - as in code where you get lost in layers and layers of abstractions and redirections and need weeks or longer to figure out how anything actually works.

So far, the best solution we have seen here: We use git and let the team do reviews of each pull/merge request. The team has a vague collection of code standards, but most important requirements are that code should solve the actual problem (obviously) and the reviewer should be able to understand how it works without too much ado.

Maybe, after all, this one still holds true: mobile.osnews.com/story.php/19266/... ;)

Collapse
 
salavora profile image
Salavora

This is great!

Since I work in SAP-ABAP programming (everyone can see your code, as long as they have the right permissions), I worry to often about clean and legible code, even for "use this one time and never ever again".
Now, I think I will "simply" mark such code this way (especially love the last two!)

Thanks!

Collapse
 
neo profile image
Neo

I'm a bit of a perfectionist too and I like how you related them nicely written!! I never really considered it like this. A thing or two to learn