The Ephemeral Art of Whiteboard Architecture
Description
A four-panel comic from 'sourcreamcomics' illustrating a common software development scenario. In the first panel, three developers agree to whiteboard a problem. The second panel shows two of them at a whiteboard, engrossed in a technical discussion with dialogue like 'WE SHOULD USE THIS MICROSERVICE,' 'BUT THAT WON'T WORK WITH THIS API!,' and 'WE MAY HAVE TO REFACTOR THE BACKEND,' surrounded by scribbles. The third panel, labeled 'LATER...,' shows two developers proudly announcing, 'I THINK WE FOUND A SOLUTION THAT WORKS!'. The final panel reveals their 'solution' on the whiteboard: a complex, abstract, Picasso-style painting of a figure in a city. One developer says, 'LET'S TAKE A PICTURE FOR FUTURE REFERENCE.' The comic humorously critiques how complex architectural discussions can result in diagrams that are indecipherable without the original context, making the act of 'documenting' them by photo hilariously futile
Comments
7Comment deleted
The half-life of a whiteboard architecture diagram's usefulness is about 30 minutes, or until the first person leaves the room to get coffee
Pro tip: once the microservice topology on the whiteboard crosses into cubism, just snap a photo and file it as an ADR - interpretation is tomorrow’s SRE problem
After 15 years of architecting distributed systems, I've learned that the most permanent documentation is always the 'temporary' whiteboard photo someone took during that one meeting where we solved everything with boxes and arrows that nobody can decipher six months later
This perfectly captures the senior engineer's dilemma: you start with a simple problem that could be solved with a function, spend three hours debating CAP theorem implications and event-driven architectures, and end up with a whiteboard that looks like a Jackson Pollock painting crossed with a microservices topology diagram. The 3D glasses are a nice touch - because by the end, you need extra dimensions just to comprehend what you've architected. The real kicker? That photo will be referenced in exactly zero future discussions, but it'll live forever in the team's Confluence graveyard, right next to the other 47 architecture decision records nobody reads
Whiteboarding microservices: where consensus emerges not from clarity, but from collectively agreeing the scribbles are unreadable - now screenshot for the inevitable post-mortem
If your system design exists only as IMG_7321.jpg in someone’s camera roll, you don’t have microservices - you have folklore
Whiteboard-driven architecture: we argued microservice vs API refactor, found a path, and published the ADR as a selfie named IMG_2137 - future us will debate whether that squiggle was an event bus or Dave’s elbow