Low-Technology

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.

This entry was posted in coaching, low-technology, opinion, practices, TDD, teams, XP. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

12 Responses to Low-Technology

  1. air jordan says:

    colin – excellent observations. i’ve been mulling some of the great comments here over and kind of centering on your analysis (though not so pithy and straight to the center!). so many times it’s just damned fundamentals and OO isn’t even the start. it’s coupling and cohesion which have been around since structured programming days and implicit even in cards (!).

  2. Dave Laribee says:

    @colin – excellent observations. i’ve been mulling some of the great comments here over and kind of centering on your analysis (though not so pithy and straight to the center!). so many times it’s just damned fundamentals and OO isn’t even the start. it’s coupling and cohesion which have been around since structured programming days and implicit even in cards (!).

  3. Colin Jack says:

    @Dave
    Yeah that matches my experience. To me there are two aspects.

    First its a natural progression of levels. Don’t bother with DDD until you have some knowledge of analysis, OO, and refactoring (among other things). DDD then acts as part of the foundation for further practices at higher levels, whether its business-driven SOA or DDDD.

    The second bit is preconditions, like access to domain experts for DDD or good-access to the right people to start with capability modelling. These preconditions are often outside your control, if the company can’t identify/provide access to domain experts then there is nothing you’ll be able to do about it.

    So to me OO is a good example of something that acts as a foundational for higher level practices and which has fewer preconditions. Obviously doesn’t mean its easy to learn or is basic.

    Anyway very interested in reading your further posts on this topic.

  4. Dave Laribee says:

    @craig i can see your point, kind of. tdd is also an excellent way to learn some of these concepts naturally. that is, as you progress in creating simple, testable designs you will naturally get better coupling/cohesion numbers, etc.

  5. Dave Laribee says:

    @colin exactly what i was thinking.

    obviously this is an iterative thought. it might be total BS. might be… in coaching, however, i find that it’s the simple, lo-fi stuff that really makes a difference. has very little to do with flexing your c# muscles or syntactic sugar or vast knowledge of a pattern language. etc.

  6. Colin Jack says:

    At first reading this seems odd but I can see where you are going with it.

    I agree on DDD too. Its great but applied incorrectly, no access to domain experts or developers with limited interested in domain or low object-orientation skills, it can be an utter disaster.

    On the other-side things like TDD and agile processes can deliver real value almost immediately, obviously you get better as you get more experienced with them but in my experience they are useful from the start.

  7. BjartN says:

    I am not sure I would call DDD high technology. If you apply DDD correctly the complexity of your solution should ideally (yes, ideally) not be more complex than the essential complexity of the problem you are solving. I guess what I am saying is that if you solve a complex problem the technology you would use to solve the problem must be a liiiitle bit complex as well. There is no way around it. Perhaps. Maybe.

  8. Neil Kerkin says:

    Just because a “practice can be completely comprehended by a single individual, free from increasing specialization and compartmentalization” doesn’t mean it is the most efficient or cost effective method of production.

  9. Chad Myers says:

    I was totally thinking “Snuggie” the whole time I was reading this. I have it on good authority that Dave owns a snuggie and wears it while watching “Law and Order” reruns on Friday nights.

  10. Dale Smith says:

    For some low-tech tools inspiration, check out “Hand Tools: Their Ways and Workings” by Aldren Watson.

    http://www.amazon.com/Hand-Tools-Their-Ways-Workings/dp/0393322769/ref=sr_1_1?ie=UTF8&s=books&qid=1256850939&sr=1-1

    Classic text by an accomplished craftsman in another much older discipline.

  11. Philip says:

    To be honest, I really don’t see how you can classify test-driven development and XP as “low-tech” and domain-driven design as “high-tech”.

    Clearly, people have a hard time understanding and applying XP and test-driven development. They require specialized knowledge at the same level as DDD, and require no less capital investment.

    And “fluent madness”? To be honest, that is so vague a statement it’s hard to figure out what you mean, but in my view, I can not see how anyone can say that “fluent” interfaces take more knowledge or investment than XP!

    It seems more to me that rather than a “low-tech” list and a “high-tech” list, you have a list of “things I personally understand or like”, and “thing I do not”.
    If this is in fact the case, applying low-tech and high-tech labels to them then extolling the virtues of low-tech over high-tech would then be nothing but strawman arguments.

  12. Craig says:

    TDD isn’t low technology IMHO. To do TDD, you need to learn the TDD way of programming, which requires interfaces, loose-coupling, OOP, etc. Many developers have not mastered even these basic concepts. Then you need to learn some Unit Testing framework like NUnit or XUnit. Then you need to learn DI / IOC and a container framework like StructureMap. Then you need to learn mocking and stubbing and a framework like Rhino or Moq. This doesn’t seem to be low overhead or learning curve. I’m not knocking it I just think it could be simpler.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>