(What follows is an extract from Out of the Software Crisis, lightly edited to work as a blog post.)
The programming pop culture defines change—any change—as progress. Most developers, myself included, have a fascination with novelty. If it’s new, then it must be an improvement. You even hear this stated outright as an argument by developers: it’s newer and therefore better. Trends in software development are rarely based on objective observation or sensible practice. This endless chasing of trends leads to projects being needlessly rewritten, code being abandoned, and new projects being started when fixing the bugs in an old project would have done the same. The stocks of the software development system are flushed out at a moment’s notice simply because the developers found something shinier.
Experienced developers are aware of this tendency in themselves and work to mitigate it, but younger developers are often under the mistaken impression that this is how software development works. Unless they can pare back this tendency or are matched with teammates who hold them back, this tendency can lead to immense destruction of value for an organisation.
Pop cultures favour the visual aesthetic of the day. We all know what sort of aesthetic designers commonly favour. Small, low-contrast text, lots of whitespace, no pure whites or pure blacks (just greys). The details vary with fashion, but each generation of designers has a preferred visual aesthetic. That aesthetic tests poorly; the text is illegible; the layout doesn’t have enough contrast. The information density is so sparse it’s effectively non-existent.
Looks pretty, though.
Coders have a similar tendency, their preferred aesthetic is just a bit different, but as with designers, it tests horribly when put in front of genuine users. The exact details of the preferred aesthetic tend to vary from generation to generation. One group prefers light-on-dark text (despite not suffering from conditions that benefit from dark mode) and unusable hyper-complex layouts where everything is configurable. Another group goes for ultra-minimalism where nothing is shown by default. You constantly scrub around and hunt for a button, a widget—anything that even vaguely resembles an affordance. This is usually not an issue if you have designers on the team. If you’re letting the programmers design the user interface or are a programmer designing a user interface, you need to be aware of it.
But this adherence to a specific aesthetic isn’t limited to designs. It’s also an issue when it comes to the code itself.
As with all of these pop culture trends in programming, this led to unreadable code that was impossible to work with or fix as soon as it faded from popular consciousness.
The current trend is towards the aesthetics of correctness. Everything has to look like it has strong or static typing. It doesn’t have to really have static typing. That can all be made up after the fact in a declaration file. It merely needs to have the aesthetics of types. Type annotations everywhere, implementing logic through type system trickery, and forcing any and all dynamism out of the system in the name of correctness is the name of the game.
A part of this trend is the unpopularity of the approaches and languages that are seen as less rigorous. CSS is dropped in favour of statically typed CSS-in-JS approaches. HTML is dropped in favour of a strict inline XML-like markup format called JSX. Just a few years ago, everybody in web development hated and dropped XML and XHTML specifically because it was too strict and felt less dynamic and flexible than HTML. At some point, pop culture will bore of this and swing its attention back the other way.
It’s a fashion industry. Trends come; trends go. The lack of historical awareness is considered by most to be a feature.
This rigour is useful in moderation. Static typing does prevent bugs. Usually, they are the same sort of bugs unit testing prevents. Both have immense value as tools to manage your software development. Currently, the fashion is to favour static typing over unit testing for establishing a certain base level of correctness in your code. At some point, they are likely to switch again. They have a couple of times in the past. That you could use both at the same time and get the benefits of both doesn’t enter the discourse. Static typing with compile-time correctness checks has its uses. So do dynamism, extreme late binding, and metaprogramming. Most of these approaches can be used together, but that isn’t how pop culture works. Pop culture demands there be only one winner at a time. Choose one, not whichever works the best at each time.
Product development can’t indulge in being pop culture. Be wary of these popularity contests.
These issues with programming culture aren’t new.
Jamie Zawinski calls it the “Cascade of Attention-Deficit Teenagers” model. We can’t do much to change the nature of the field by now—Alan Kay has certainly tried—but we can mitigate the harm done by the trend-seeking. We can work to ensure that everybody on the team, programmers and designers, is aligned, and have the same understanding of what matters and how to accomplish it.
For that, you need everybody to understand the context they are working in—the works of their field and how they are received. You need to develop taste and understanding.
You need research.
Bonus Alan Kay quote on programming as a pop culture that I didn’t include in the book:
Out of the Software Crisis
Software projects keep failing, not because we don’t have the right team or tools but because our software development system is broken. Out of the Software Crisis is a guide to fixing your software projects with systems-thinking making them more resilient to change and less likely to fail.