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 bathroom - only the bottom part of the window was made from frosted glass. The top half was crystal clear and would expose everything that happens in the bathroom to the neighbors on upper floors.
He needed to cover the window to have some privacy.
The proper solutions to covering a window are curtains, shutters, roller blinds, or frosted window film. The first three have the advantage of having two states, the window can be either covered or uncovered without dismantling the thing, but they also block the sunlight. The last one covers the window all the time but lets the sunlight in.
All of them require planning and money, and are not doable on a single evening, especially when the shops had already closed for the day.
My boyfriend needed to take a shower in that bathroom that evening.
His solution - tape a piece of cardboard to the window.
Almost a year later, that window is still covered by the same piece of cardboard. Why? Because it was the solution with the highest ratio of value to cost.
- It was quick and cheap. The required materials, tape and cardboard, were already in the apartment.
- It is effective. It completely stops the neighbors from seeing what they should not see.
- It is not a problem that the cardboard stops sunlight. The bathroom already gets plenty of sunlight from the bottom window.
- It is not a problem that the window cannot be easily covered and uncovered without tearing down the cardboard. The window is too high to reach without a ladder.
- It is not a problem that the cardboard is ugly. We do not really care.
- There are no young and impressionable interior designers coming over to our apartment, looking at that window and thinking that a cardboard stuck to the window is a good design pattern.
So... what's the point?
This is just a silly example, but it made me think about how I approach the quality of the code I write and the code I expect from others.
I suffer from perfectionism. My coworkers complain that I can be too demanding of them (but also of myself). Sometimes I catch myself being really stubborn during a code review (sincere apologies to everyone that was ever affected). If that happens, I try to stop and ask myself - what is this code for?
The value of the code is the usability it brings to the user, not its cleanliness or beauty.
The price of the code is the time and the energy spent to develop it.
Usually, bad code is expensive. Bad code is hard to understand. Bad code is hard to debug. Bad code is hard to extend. Because of all of these reasons, bad code also decreases the value that can be delivered in the future.
But sometimes, just sometimes, you know you are writing code that will never again be read, and will never be modified. You know it will be used, maybe just once or twice, and then it will be thrown away. That is when bad code is cheap.
I understand now that a 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. Even if that means writing a quick dirty hack once in a while.
Oh, but try to make sure no young and impressionable junior developers will come over to your code base, look at that bad code and think it's a good design pattern since a respected developer like yourself wrote it. Maybe leave a word of warning in a comment?
# Here be dragons!
# Forgive me, Father, for I have sinned...
# ~~~ POLICE LINE DO NOT CROSS ~~~ POLICE LINE DO NOT CROSS ~~~
# I was young and I needed the money.
Top comments (11)
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.
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 ☹️.
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
I would rather the dev encapsulate the hack in a function with a indicative name,
function myDirtyHack(...args) {...}Great idea! I should use the next time I have such a need.
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.
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
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 :)
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/... ;)
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!
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