Systems
A new gestalt
Why aim small?
The number of ways in which things work
Inputs and outputs
Taylorism
Sets and systems
Every paper cut is felt
Technology is a system
Technology is not the sum of the artifacts, of the wheels and gears, of the rails and electronic transmitters. Technology is a system. It entails far more than its individual material components. Technology involves organization, procedures, symbols, new words, equations, and, most of all, a mindset.
Notes on the Legibility War
An Article by David R. MacIverThe basic idea of legibility is that the act of making something comprehensible enough to control is itself an act that shapes the thing to be controlled, often with far greater consequences than the control itself. This is because it removes complexity that is deemed as irrelevant that makes it harder to control, and that complexity may be in some way essential to the health of the system.
Primitive design
An Article by Matt Webb- I want it to feel intuitive
- I want any new features to be platform features, not one-offs.
And the second of those is weird, right? It’s like sketching out a toy spaceship, having a list of rules about play, and attempting to simultaneously invent the shape of the Lego brick.
That’s platform design I suppose. Redesigning a newspaper will mean bouncing between comps and style guides, designing both. Inventing the iPhone user interface will have seen apps and app paradigm evolving together.
Design Systems, Agile, and Industrialization
An Article by Brad FrostI’ve come to the conclusion that “enterprise web development” is just regular web development, only stripped of any joy or creativity or autonomy. It’s plugging a bunch of smart people into the matrix and forcing them to crank out widgets and move the little cards to the right.
In these structures, people are stripped of their humanity as they’re fed into the machine. It becomes “a developer resource is needed” rather than “Oh, Samantha would be a great fit for this project.” And the effect of all this on individuals is depressing. When people’s primary motivation is to move tickets over a column, their ability to be creative or serve a higher purpose are almost completely quashed. Interaction with other humans seems to be relegated to yelling at others to tell them they’re blocked.
Reading “AS PER THE REQUIREMENTS” in tickets makes me dry heave. How did such sterile, shitty language seep into my everyday work?
When Customer Journeys Don’t Work: Arcs, Loops, & Terrain
An Article by Stephen P. AndersonThinking [in terms of loops and arcs] allows us to let go of a specific journey or sequence, and imagine dozens of scenarios and possible sequences in which these skills can be learned. This doesn’t mean there aren’t more fundamental skills that other skills build upon, but we can let go the tyranny of how, precisely, a person will move through a system. We’re free to zoom in and obsess on these loops, which does two things for us:
- Approach the design of a system as the design of these as small but significant moments of learning.
- Consider the many ways these loops might be sequenced, with the exact order being less important.
Stress systems
An Article by Ethan MarcotteThe [Lake Erie] ecosystem underwent a series of changes, each of which were related. There was an increase in the human population; which led to higher phosophorus levels in the water; which led, at last, to an increased level of algae in the lake. In effect, Lake Erie’s ecosystem was rewritten. Changed by human activities into…something else.
But Franklin cites the study because it’s doing something slightly novel: applying Selye’s principle of stress to ecological systems, suggesting that they are, much like humans, just as susceptible to external stressors. And I’ve been thinking about that a lot lately, especially this week. Because Franklin’s suggesting that the work begins not by “fixing the system.” Rather, she suggests it’s about shifting the priority a little: to removing whatever stress you can.
The Art of Systems Architecting
A Book by Mark W. Maier & Eberhardt RechtinThe design systems between us
A Talk by Ethan MarcotteIn the early days, design systems promised us more consistent interfaces, more collaborative teams, and improved shipping times. While they’ve certainly delivered on some of those fronts, they’ve introduced new challenges too. Let’s talk through what’s working well—and what could be working better—as we take a closer look at the systems between us and our work.
Design System as Style Manual With Web Characteristics
An Article by Dorian TaylorIn my opinion, what makes a designer competent is precisely their ability to credibly justify their conclusions. If you can’t do this as a designer—no matter how successful your results are—then neither I nor anybody else can tell if you aren’t just picking things at random.
What I am proposing, then, is no less than to make a designer’s entire line of reasoning a matter of permanent record. On the surface is the familiar set of prescriptions, components, examples and tutorials, like you would expect out of any such artifact. Attached to every element, though, is a little button that says You click it, and it tells you. The proximate explanation will probably not be very satisfying, so you click on the next until you get to the end, at which point you are either satisfied with the explanation, or you aren’t.
Now I get it
An Article by Ralph AmmerTo design a system means to orchestrate the interplay of its elements.
Such a system is considered “interactive” if it is open, which means that there are ways to engage with the processes that are happening inside of it. There is of course a range of interactivities which spans from very basic reactive behaviour to highly complex conversational interactions.
Deadlines are bullshit
In software development deadlines are a necessary evil. It is important to understand when they are necessary, and it is important to understand why they are evil.
- External vs. internal deadlines
- Why are internal deadlines evil?
- Engineers who love their work
External vs. internal deadlines
When are deadlines necessary?
- Contractual obligations
- Technical liabilities (e.g., dependency EOL)
- Compliance, government, investors, and other external stakeholders
What do all of these deadlines have in common? They are all important. They are all deadlines that cannot be missed. They are all external.
When are deadlines evil?
- Your manager says you have a deadline
- Your software development methodology says you have deadlines
What do all of these deadlines have in common? None of them are important. They are arbitrary. They are all internal. They are all bullshit.
Why are internal deadlines evil?
- Estimation: When estimating engineering work a substantial time investment is required by an engineer in order to get an accurate estimate.
- Misaligned Incentives: There is an incentive to lie and give estimates much longer than the feature is truly expected to take.
- Low Morale: Deadlines are likely to be missed often. Repeated failure has a cost to the morale of the team.
- Micromanagement: Deadlines are wielded by middle managers as a whip to harass and annoy engineers working on features.
- High Stress: When engineers feel the pressure of other stakeholders holding deadlines over their heads it creates an environment of high stress.
- High Turnover: On teams with high turnover rates the best engineers have an easy time finding new work and leave quickly, the worst engineers have a difficult time finding work and remain. This selects for a lower quality team over time.
Engineers who love their work
The resolution is simple. Never have internal deadlines. Operate on a prioritized and ordered list of features. Estimate only when necessary to prioritize and do so in a t-shirt sizing way. Trust your engineers and they will begin to love their work. Engineers who love their work are happy and productive.