Engineering by Email is Evil
Have you ever been part of an email thread at work that starts out with an innocent question like, "what's CPU usage on cluster alphabet?" but then devolves into a highly technical planning session with multi-paragraph diatribes about design decisions and flimsy, off-the-cuff justifications? It usually spirals into chaos soon thereafter as disagreement abounds. And decisions are made based on who replied to the thread (which is saved by everyone as a "get out of jail free" card).This is engineering by email. And it is pure evil.
I've developed an informal method for determining when engineering by email is occurring: I look at the height of the scrollbar relative to the height of the window. If the scrollbar's height is 1/4 or less of the window's height: run. And let's not even talk about how horizontal scrolling is widely understood to be a bad UX idea.
Engineering is a process, just like design, digestion, and the Xiphoid. Ok, maybe not just like those things. But it's a process nonetheless. It requires a deep understanding of your requirements, constraints, assumptions, and other influences. It can't simply be typed into existence in response to an email. And email is certainly not a suitable repository for such documentation.
“But no one uses email anymore! We use slack! We use Teams! We used Cisco Webex Teams! We use HipChat!”
Oh shut up already. Everyone uses email for work. No temporal walled garden app will kill email. But I’ll entertain that thought a moment and tell you that if you use any of these messaging platforms as your primary source of inter- and intra-office communications, then the same applies.
In many ways, we’ve lost the true meaning of engineering. It’s a process, not a product. A science, not a suggestion. Engineering isn’t a one-line message that says, “Maybe we can use the DR site since it has excess capacity?” That’s an idea, part of a brainstorming effort. It can influence engineering, but on its own this is NOT engineering.
Duress-Driven Design
You can't build something out of fear. Your motivation can't be to not get fired or publicly shamed. These conditions lead to duress-driven design. And like engineering by email, it is also pure evil.Your project timeline needs to reflect the enormity of the problem you're solving. While we all like to take our turn as the superhero that saves the day by delivering an amazing solution in a highly compressed time frame, we’ll only burn out all the faster for it. And bypassing development, or feverishly condensingit, is never a good idea.
