There are tasks that computers are good at. And there are tasks where they aren’t. One driver of the evolution of the personal computer, laptops, mobile phones, and all forms of mobile computing has been the desire to increase their range: do more; in a smaller package. Many in tech and software are addicted to riding this wave of new capabilities, however long it will last, to work on and create new software. To extend the reach of the computers in our lives.
Innovation’s the word. Pushing the boundaries. You know the phrases. Usually spouted by that dude at the party.
The other side is also interesting. We are now in a place where we have entire genres of software that have decades of history, are backed by stacks of new and old research, have dozens of successful, well-made exemplar apps, and a broad enough conceptual space to allow for new variations on the theme. In short, we have genre software and we have avant-garde software
If you ever wondered why so many people use their email to organise all of their work, this is why. It’s the only user-subjective information management tool at their disposal.
Just because implementation is a second order concern doesn’t mean there isn’t real value in accelerating the implementation, as long as we frame it appropriately behind an interface that simplifies access to the underlying capability. Unsurprisingly, accelerating implementation is precisely the main value proposition of commercial integration DSLs.
A number of integration DSLs are marketed to “own” the integration landscape, and to call out to a general purpose language when necessary. To address programming-over-time concerns, you’ll want to invert that control, abstracting the parts of the implementation subject to evolution complexity from those that are unlikely to require much change over time.
This is what worries me about design thinking: its colossal and seductive promise. There was an earlier Anglo-American vogue for design — a love affair with industrial design, beginning in the Depression era — but it was relatively benign in its claims and its outcomes. This more recent vogue for design thinking seems more insidious because it promises so much more. It promises a creative and delightful escape from difficulty, a caper through the Post-it Notes to innovative solutions. And it promises this as a service, delivered at what is often great cost — not just to IBM and Intuit and Starbucks, but to villages and nonprofit organizations and cities like Gainesville without enormous resources to spare. There’s another problem, too. By embracing “design thinking”, we attribute to design a kind of superior epistemology: a way of knowing, of “solving”, that is better than the old and local and blue-collar and municipal and unionized and customary ways. We bring in “design thinkers” — some of them designers by trade, many of them members of adjacent knowledge fields — to “empathize” with Kaiser hospital nurses, Gainesville city workers, church leaders, young mothers, and guerrilla fighters the world over. Often, as in Gainesville, the implicit goal is to elevate the class bases of the institutions that have organized their informants’ lives. Only within this new epistemology can such achievements be considered unambiguously good.
And yet this is the ur-story of the multi-act American romance with the idea of design. Americans love design most when we’re afraid. Just as the Depression enabled industrial design to present itself as the solution to US manufacturing woes, the 2000 to 2002 dot-com crash and 2008 recession, with their long tails, have enabled the rise of a new embrace of design and a new broadening of design’s imagined jurisdiction. This time the specific fear is that the knowledge economy is coming for everyone. Bewildered and anxious leaders, public and private, have responded by throwing in their lots with the seemingly magical knowledge-work that is design.
But design isn’t magic. To address a wicked problem is to look for its roots — and there’s no hexagon map for getting there. Stop at “insufficient competitiveness” and what you get is a solution that can be tidy exactly because it doesn’t touch the deep causes of Gainesville’s economic stagnation. You get a solution that’s indifferent to the legacies of slavery and segregation, to the highway projects that systematically cut off and blighted East Gainesville, to East Gainesville’s miserable public transportation, and to Florida’s $8.46 minimum wage. Stop at that top turtle and you miss that it’s turtles all the way down.
Better to acknowledge, as Rittel wrote in 1988, that the top turtle often obscures real, substantial, and inconvenient difference. There is no consensus as to how resources should be distributed, social life arranged, justice done. To design, really design, is to acknowledge those divergences — and then to listen one’s way, and push one’s way, to somewhere new. Such battles from competing positions can be truly wicked, Rittel believed, but it’s better to fight than to obscure irresolution with optimism. He had a point. Design may come in an elegant package, but it doesn’t always make things right.
Pikchr (pronounced “picture”) is a PIC-like markup language for diagrams in technical documentation. Pikchr is designed to be embedded in fenced code blocks of Markdown or similar mechanisms of other documentation markup languages.
For example, the diagram:
Is generated by 7 lines of Markdown:
``` pikchr arrow right 200% "Markdown" "Source" box rad 10px "Markdown" "Formatter" "(markdown.c)" fit arrow right 200% "HTML+SVG" "Output" arrow <-> down 70% from last box.s box same "Pikchr" "Formatter" "(pikchr.c)" fit ```
Gruescript is a tool for creating point-and-click text adventures which feel like classic “puzzlebox” games while eliminating the need for the player to type, making the games friendly to modern devices and players. You build your game online and download it as a playable HTML page, which you can host on your own itch.io site or elsewhere.