Welcome to the fifth issue of Growing the Stack! The newsletter was on an unannounced summer break, but we’re back on schedule with a new issue every second Tuesday.
“Three links” isn’t set in stone anymore, but the amount of content shared will still be roughly the same. This week contains four links, two about programming, and two that cross over between programming and design.
Ross Tuck shared a shitty article about software quality guided by his “Everybody poops rule”.
Everybody poops. But you don’t poop in every room in the house. You have a special room where you poop, you put a door on it and you only poop there.
A program is never “done”, and in turn will never be perfect. It’s important to differentiate between parts of a codebase are worth investing in, and parts that can be crappy, as long as they’re contained in their own space.
The Everybody Poops rule is about admitting some parts of a system will be… well, crap. Not every part of the system could or should be top tier quality. Eventually, everybody poops. It’s a natural process.
Just because you can manage poop successfully doesn’t mean you should do it everywhere. No amount of engineering will ever make a kitchen toilet a good idea. Similarly, don’t crap in the domain layer.
Matthias Noback—who has managed to blog consistently every week this year 😯—shares his experience applying “consistency” rules to his objects.
When you create an object, it should be complete, consistent and valid in one go.
In the post, a geolocation service gets a refactoring treatment. Matthias goes through multiple iterations, each with their own tradeoffs.
It is derived from the more general principle that it should not be possible for an object to exist in an inconsistent state. I think this is a very important rule, one that will gradually lead everyone from the swamps of those dreaded “anemic” domain models. However, the question still remains: what does all of this mean?
Despite the title, the beauty of this article isn’t in a quick guideline, but in the refactoring process that we get guided through.
I recently stumbled across this idea in a Hacker News comment.
The principle of least astonishment applies to user interface and software design. A typical formulation of the principle, from 1984, is: “If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.”
In general engineering design contexts, the principle means that a component of a system should behave in a way that users expect it to behave; that is, users should not be astonished by its behavior
In my experience it’s often a good idea to draft your program’s public API before actually building it. Don’t let implementation details influence design.
Amber Case expresses her frustrations towards the use of touchscreen in modern machines. Being software-driven, touchscreens are a lot more flexible than analog interfaces, but they come with their own tradeoffs.
Serious interfaces — those that are repeatedly used by a knowledgeable professional and/or in potentially hazardous situations, should not be touchscreen based. If a touchscreen must be used, it should be embedded alongside a set of fixed, physical buttons that support muscle memory and single actions.
My takeaway is that we should stop making everything more “high-tech” for the sake of it, and shouldn’t be afraid to take a step back and evaluate our creations from first principles.