I’ve been pondering a comment Michal Migurski made on Adam Greenfield’s blog about how hard hardware is (he says how easy software is, but in the context of doing hardware)
Even as I plug jumper wires into my breadboard, I’m aware of how much more powerful and easy it is to do things in software, and how much more reach you get through a web browser. Olinda has physical slots for six “friends” on its hardware social unit – revolutionary for a radio, but a meh replacement for an iChat buddy list that *scrolls*.
Why is hardware harder and less powerful than writing some software that can be experienced through, for example, a web browser, or an operating system? Or..is it something about the materiality of hardware that changes things into hard problems to solve. Certainly software is “easier” in the sense that you can more-or-less sit still, get zen and code. And finding the right tools nowadays, with online communities and such makes the route to solving problems less onerous.
I tend to think that it has something to do with the communities — the real toolkits — and their ability, from the grassroots, to work with the material. Both software and hardware have been (and in many instances, continue to be) economic commodities — someone’s trying to make a buck. Nothing wrong with that, of course. But hardware has been particularly expensive, partly because it’s material stuff, with weight and elaborately toxic and costly process costs. But, also because very few companies have had the foresight to consider how free or subsidized hardware could be a smart, strategic investment. Atmel, makers of the microcontroller that goes into Arduino’s, had that kind of foresight. They’ve underwritten most of their development kits so that they literally loose money. Their kits and programming tools are top-notch and it’s barely fair to complain, although some do, and I bristle when a tinkerer grouses about a $30 programming module. This of course from the vantage point of a hardware geek going back to the late 80s, where scoring a Xerox 820 at a Ham Radio fair set me and some buddies back a few hundred bucks, no O/S, barely any documentation. Now you get an open model — everything is revealed to you, there’s support for GCC, etc.
If I were to make a prediction, I’d guess that hardware will become more relevant not just “cause” but for the ease with which it will be possible to “code” your ideas in various interesting and hopefully playful and even preposterous ways, and the linkages between idea-objects will be as routine as TCP/IP is today. (This is already happening at the fringes. I just recently received a bit of hardware that sits atop an Arduino and allows it to talk over a standard TCP/IP link. Open hardware, open software — your own programmable networked device for about $70, all in.
Eh, I think you’re on to part of the issue – the availability of simple toolkits. But, I also think hardware requires a set of skills that is not readily taught anymore.
Software skill teaching is more prevalent, so we are more used to dealing with it. Also, I think software is more forgiving, allowing the coder to get away with poor code or working around limitation with simple glue code.
Hardware requires less-common skills, is what it is, and requires a deeper understanding of the material.
I agree that hardware folks need to make more kits. But at the same time, our current world is so focused on pixel-pushing and coding, that we’ve sort of lost our skills for working with hardware.
Tchau!
PS Heh. When I read the title of this post, I _was_ going to plug what I used to work with: bacteria, DNA, and proteins. Krikey, they are finicky to work with. But, after reading this article, I think there is as much hope for biotech tools as there is for hardware.
Indeed, the past 15 years has seen an amazing simplification in the tools – what took a post-doc 6 years in the 1980s now can be done by a tech squirting something in a tube and sending it off by mail (to get the results by email). And there are groups working to take the simplicity further to jump start tinkerers in biotech.
It’s the materiality.
Stuff has mass, stuff has consequence. And so not merely does stuff enjoy a lower velocity than code, but (as you imply) the entire community of practice that’s grown up around stuff these last four, five centuries is pretty conservative. With reason, right? There’s no Ctrl-Z for granite.
I’m with you, I hope some of those attitudes change, driven by just the sort of simply extensible hardware you’re talking about. But I’m not expecting it to happen anytime soon. Here’s Bryan Boyer’s take on the selfsame comment – which, BTW, I endorse:
“When I try to tell my inquisitors that architecture and information “architecture” are not the same thing, that physicality is a bitch, that 1:1 prototyping with real matter (!) tends to be prohibitively expensive given the way architectural practice is set up their eyes glaze over. Look, I’m as optimistic as anyone else, I love the web, I love software, I’ve been through those trenches. But if you want to start talking about some serious cross-disciplinary pollination then you better take both sides of that disciplinary divide seriously…[T]he transformative powers of [computation] are bracketed pretty seriously by the realities of the physical world.”
As a professional (if uninspired) software guy, and a self-taught hardware enthusiast, I have thought about this subject a lot. Obviously the materiality of hardware matters, but it is more then that.
Software is in some sense axiomatic. If I know the language I can write anything. Every for loop works like every other for loop. It is a closed and abstract system, and there is no need to worry about external influences. There is never a case where the frequency of one switch statement will cause interference with a nearby switch statement through capacitive coupling.
Similarly there are differences in the way one can learn hardware vs. software. I can read code, it is all there (ignoring external libraries). While I can (sort of) read a circuit diagram there are lots of things one simply has to learn which must be plied before you can really understand what you are looking at. Why is that a shottky diode? Why use a tantalum capacitor instead of an electrolytic? As a beginner these form the barriers to entry which make experimentation feel so hard. I can’t just cut and paste some stuff together and see what happens. The cycle of process is much longer. Not to mention that I have never let the smoke out a $20.00 software component by plugging it in backwards!
There is an entire different level in which the craft of hardware is different as well. It is physical, and requires an ability to think and work in 3d. To control small parts as you apply complicated processes. You have to learn to see which solder joint is bad and feel which 1/4 watt resister is getting too hot.
I think we can modularize hardware to the point where it is all plug and play (the arduino is providing an start and I love it for that reason). But you will obviously loose the flexibility of being able to go down to first principals and build a circuit that does exactly what you want and does it in the most efficient way.
I just came off four days of seriously sweaty, material trekking on the Inca Trail – the canonical prototype for the Internet where “bits” were fast-moving couriers (50-some miles in as short as 3 hours 12 minutes, current world’s record which, I have to assume, is as fast as it may’ve been during the Incan empire.) There are lots of amazing things about the Trail’s hardware, most obviously its expanse, the way your imagination cannot grasp how it could be possible to materialize it. It’s just not possible. How could anyone make such a thing? Yet, that kind of hard hardware exists. 500 intrepid trekkers start a trek on it every day. Every day there are, somewhere on the 50 miles of this one particular trail, 2000 people being routed along the network.
The Incans and their people must have had incredibly robust toolkits, not the least of which were there sense of participation in a vast civilization that supported their lives. I can only imagine, but things like cutting tools to turn random rocks into formed steps. Systems of clearing trails, moving food and water up the trail, rotating labor – everything in place to construct the hardware of the network. There wasn’t a question about materializing it and “hard” can only be relative to what is easy. Not having the ability to communicate or to transport must have seemed a harder way of existence.
I don’t know if its inevitable that more toolkits will support the construction of interesting hardware assemblages. But only because the social practices of people at the fringes are playfully engaging in these activities, my inclination is to imagine hardware will get easier, more interesting and lots more fun.
Today, software is easier in the ways described above, and I agree in certain ways. But the relationship between the two is so deeply imbricated that I wonder if there is something to be gained by not doing this kind of ontological bifurcation between soft/firm/hard ways of inscribing “codes” for doing things.
Software has a big advantage: cut-and-paste!
Though the community must be important, too! So many people have computers. But how many have a soldering iron?
I agree with Josh. Hardware is hard because the abstraction breaks down more easily. You have to worry about whether your 3.3V microcontroller has 5V tolerant inputs, you have to worry about bypass and decoupling capacitors, you have to worry about how much current you’re pushing through your LEDs or transistors, you have to worry about the power-up sequence and make sure everything is held in reset for just the right amount of time…and if you mess up one tiny single little detail for even a brief moment it’s possible that you’ve just irreversibly broken it.
On top of that, software is almost universally equivalent, whereas hardware is almost always different. You can’t just port C code from one microcontroller to another. Port A on one MCU is at a different address than port A on a different MCU.