I’m completely obsessed with the idea of low-technology:
The term low-technology is a description of those crafts and tools whose inception (typically) predates the Industrial Revolution.
A test for low-technology may be that it can be practiced or fabricated with a minimum of Capital investment by an individual or small group of individuals; and that the knowledge of the practice can be completely comprehended by a single individual, free from increasing specialization and compartmentalization.
An excellent overview of some of the cutting edge efforts in low-technologies can be seen in this TED video with low-technologist Amy Smith. I completely agree with when says, “not all inventions need to be grandiose, complex things… sometimes they can be simple and smart ideas that just help a lot of people.”
The second block quote is where I’m coming from. What are those tools in software development that add lots of value without minimal getting started overhead. Pair-programming seems like an excellent example of low technology. Emergent design, test-driven development and value-driven approaches like XP are yet more.
It seems, to me anyway, that these are the things that’ll yield the most benefits. Both vendor-supplied tooling and trending topics we hold near and dear, like Domain-Driven Design and DSLs and this fluent madness in general, strike me as more high-technology approaches.
There’s nothing wrong with high-technology, of course, but my instinct is that the risk-reward equation for most teams usually favors low-technology. We have, after all, limited bandwidth and attention, so my vote will ever go to what I see as big and easy wins: stuff focused on beefing up the signal of our communication as a team and community against the noise we might get as a software fashion victim.
Anyway, this is a key topic I’ll be centering on over the next little while and thought y’all might find this way of looking at our kit, our standard tradecraft at least a little bit interesting.