Software Testing and Design in the Men’s Room
It seems like testing is the hip thing to do these days. Developers are almost more proud of the tests they write than the code that makes the product work. Clone a repo from github and run the tests.
It is a great practice. Don’t get me wrong. But this is a story about how great testing, great design, and implementation all came together to produce a product with a critical flaw. This is story of the epic fail that is the men’s room where I work.
Brad Frost has an excellent write up about designing things at the component level, then building up from there.
...interfaces are made up of smaller components. This means we can break entire interfaces down into fundamental building blocks and work up from there. That’s the basic gist of atomic design.
I agree with this. And so did the designers of the men’s room. The floors, the plumbing fixtures, the tiles on the walls, all were designed independently as components. The builders took these components and worked up. Tiles together became a floor, or a wall. Plumbing fixtures assembled created sinks and toilets. All of these things together created a functioning men’s room.
Consider the components of the men’s room in the context of software testing. The tiles that were designed and built were likely tested (unit tested). The tile did exactly what the tile was supposed to do. It was the right color, had the right sheen, had the right hardness, the pattern on the back was optimal for adhering to the walls, and it was exactly the right size.
The partitions separating the toilets were also tested. Perhaps by a different team. (Think of a webpage like this you have seen...clearly built by different teams for each link). The partition walls are the right height, they are fastened to the walls properly and are able to support the doors and withstand the usage levels that they are subjected to. They were installed with those screws that you cannot remove (because everyone everywhere is always just waiting for the opportunity to disassemble a stall).
The sinks, mirrors, et cetera were all unit tested. Thinking about unit testing a mirror makes me laugh.
Implementation: Bringing it all together
Once they were installed someone walked into the men’s room and looked around. Think of this individual as the QA person. They had the specs, looked around and said, “sink over there, check. 3 urinals with dividers, check.” Testing went on... the water came out, hot and cold. Toilets all flushed. No leaking. Mirrors properly reflected. Towel dispensers dispensed. Soap things gave soap. This was a fine, fine men’s room.
Since the human race has a long history of using the bathroom, it is not likely that a lot of usability testing was necessary. Toilets had been tested before. People could use them. These were standard. Same story with sinks and the paper towel dispenser. No need.
Just to be sure, maybe one of the builders used the men’s room. Yes. It appropriately accepted his waste without judging him—all while making him feel like the king on the throne that he was.
The case for real-world testing
In the office building in which I work, there are lots of people. The bathrooms are busy places. This is a case study of where lack of real-world testing failed to expose a critical flaw. This can happen with software, and even with bathrooms that have been built 1,000 times before.
Enough already. So what is the epic flaw?
Let me set the scene. After walking in, you turn to look at the wall with the fixtures. There are three stalls on the left. On the right there are three urinals. When standing at the urinal that is adjacent to the stall, you can see, in the reflection of the tile on the wall, the backside of the person sitting in the stall next to which you are standing. Again. You can see in the reflection the person sitting in the freaking stall. Fail.
This is so offensive that people take to stringing long pieces of toilet paper from the top of the stall in order to close the gap.
Let’s put this back in software terms
The flaw here was not in the specs or design, it was in the combination of them. We have all used software like this. No one actually stood and used the urinal while someone was using the stall. Sometimes it is clear that no one actually used the software as a whole before shipping it. Everything else was perfect according to the specs: The tile was great. The stalls installed properly, the urinals, sinks, all of it. But until someone used it under the proper (and common) conditions the flaw was not exposed.
These are the answers we get when this happens in software. “Well there is a workaround. Look straight ahead. Use another urinal. Hang toilet paper up to cover the gap.”
All stupid answers.
Oh how often we do this in software. How it angers me when I see it done. It is something I am reminded of multiple times a day, every day as I choose to implement a work around in the men’s room. It motivates me to do a better job testing the software that we are developing. One of the last things I want to be is responsible for a flaw akin to the men’s room flaw.
Hopefully the image of this can help you to be equally inspired to think more about real-world testing. Think about the principle behind the software or the thing you are building. What are you trying to accomplish? You are not simply trying to build a place for someone to go to the bathroom. An outhouse meets those criteria. The principle here was a place for multiple people to use the bathroom at the same time with relative privacy and comfort. They were so close to accomplishing it. And they still could. I really wish they would fix it.
Bonus: Some other bathrooms that caused me to shake my head
For what it is worth, I take pictures of lots of things that make me wonder what people were thinking. Not just bathrooms.
Carpet? Steps? Really?