Hardware Vs Software: Fight!

It’s one of the great cliches in the hacker world: the hardware type and the software type. You can tell which of these two you are quite easily. When a project is actually 20% done, but you think it’s 90% done, and you say to yourself “And the rest is a simple matter of software”, you’re a hardware type. Ask anyone who has read my code, and they’ll tell you, I’m a hardware type.

Along with my blindness to the difficulties of getting the code right, I’ve also admittedly got an underappreciation of what powers lie in the dark typing arts. But I am not too proud to tip my hat when I see an awesome application of the soft stuff. Case in point: this Go board sequencer that we ran last week. An overhead webcam parses players’ moves as they put black and white stones down while playing the game of Go, and turns this into music.

The pure software type will be saying “but there’s a webcam and a Go board”. And indeed, that’s true. There are physical elements to this project that anchor it in the shared reality of the two people playing. But a hardware project this isn’t; it’s OpenCV and Max/MSP that make it work.

For comparison, look at the complexity of this similar physical sequencer. It’s got a 16 x 16 array of LEDs and switches and a CNC milled, primed, and painted surface that’s the size of a twin bed. Sawdust and hand-soldering: that’s a hardware project.

What I love about the Go sequencer is that it uses software just right. The piece is still physical. It could have just as easily been a VR world, where the two people would interact with each other only inside their goggles. But somehow that’s not quite as human as putting stones on a wooden board, sitting across from, and maybe even looking at, your opponent. The players aren’t forced to think about the software. They don’t feel like they’re playing a video game.

But at the same time, the software side of things makes all of the horrible hardware problems go away. Nobody is soldering a rat’s nest of 169 switches. There’s a webcam plugged into the USB port of a laptop. There’s a deep simplicity there.

Should you always trade out arcade buttons for OpenCV? Absolutely not! But is it worth considering the soft side when doing it in hardware is just too, well, hard? I’m open.

41 thoughts on “Hardware Vs Software: Fight!

  1. Hardware and software people have always thought each other were idiots to go by dad’s old grousing after work. Software seems to pay little attention to how hardware actually works and how to operate it correctly. Hardware seems to ignore the intense complexity that is usually asked of software and the terra incognita factor where the same thing is almost never possible to do the same way twice.

      1. Yes. If you started ,as i did, on a 8086 in hex. I will never forget the problems we got by switching to Asm (not everything is implemented and/or possible) luckly is was a “macro” asembler so a few missing (asm) instructions where added and later replaced by a few standard asm intructions. (compiler updates)
        The same problems (reduction of instruction usage) at going from Asm to Plm and later to Pascal the to Delphi and as latest C99.

        1. But let’s not forget P-code. And I did a lot in Forth, C, C++ and Pascal.

          These days I write code in Visual Studio – Visual Basic, and C programmers still tell me that C is the greatest programming language in the world. It’s not in Visual Studio. Whatever language you are most comfortable in VS is the one that works the best in Visual Studio.

        2. Pfffft – Macro assemblers are high-level :) I started by hand assembling opcodes for a Motorola 6800 and entering the raw hex. Made it play tunes by toggling an I/O line connected to a speaker.

          Also went to Turbo Pascal and still using Delphi (sometimes), so sounds like we followed a similar route.

        1. Is Z-machine or Brainfuck low level or high level? They are essentially running a machine code, however usually in software emulation. There are hardware implementations – Brainfuck needs only a few logic circuits and SRAM, Z-machine was implemented in FPGA.
          So, if the language on its own is defined as machine code running on virtual machine which may be at one point implemented directy in hardware, does it make the language low-level or high-level?
          And there are more examples – LISP implemented later in Lisp Machines, Java on ARM processors with Jazelle DBX extansion.
          And here is my main question: If the high-level language grows into hardware specification or hardware compatibility layer, doesn’t it make the step to low-level language?

      2. As someone doing both for a living I always looking for analogies. There is in most cases no need for a lower level than C and it wouldn’t often make sense. As complexity rises you go up the ladder not downwards. It is like saying in the Hardware world: Pfff, this engineer is using screws, look at him, that’s already “High-Level” mechanics for me. At the end every Level is not the High-Level or Low-Level, everything is just mid-level and there is good reason for any of them, just to focus on what is the issue/problem is there and to lower complexity.

  2. That’s what I like about this hobby. I get to do both aspects. My day job for 40+years is software development. I have always wanted to know how the hardware works to be more efficient with my work.

    In this hobby I can work on a 555 based circuit and then thr next one is an arduino or pi. I can figure out the transistor circuit to control something and then write code to make it work. I can move back and forth in this spectrum.

    1. Fair enough! Actually, I think that’s the perspective of a fair percentage of our readers: hardware folks working with software or vice-versa.

      And it makes sense too, because the low-hanging fruit is likely to be lurking in the domain that you’re the least familiar with.

      So when I see “software types” dipping their toes into hardware, I’m stoked.

      1. Software has been my hobby and day job for more than 30 years and it’s only in the last 10 that i started playing with hardware (yes arduino was the bridge that allowed me to cross over).

        Now i’m more likely to commit time to implement functionality in hardware because it’s easier and less time consuming than having to write, debug and maintain software to perform the same function. Filters and debouncing are good examples but there are many more.

  3. As a mechanical design engineer who switched to software 30 years ago, I don’t think there is really a lot of difference. Hardware types think in objects and interfaces, as do the best software types. Breaking down a problem into smaller, solvable checks is the essence of problem solving, no matter what the discipline. Additionally, when I look for a good software engineer to hire, I look for someone who writes well — if you can’t express yourself well on paper, there is no way you are going to be able to create coherent, maintainable code. Craftsmanship, creativity, and perseverance are important to all makers, no matter what their ‘type’.

      1. I think “checks” also works. Managing costs determines a product’s success or failure. Hardware costs are fixed and baseline. Every unit you send out will have those costs build in. Initial software costs depreciate over time. Pushing what you can push into software makes a great deal of sense in terms of material costs as well as in terms of product life. Then concentrate on making the baseline hardware more reliable.
        Oh, wait. We’re still in the midst of the throwaway society. Never mind.

    1. “I look for someone who writes well…” I don’t agree with that, reason: My letter count is low and English is my 3e language.
      Have done mechanical, hardware and software (3, 6 and 30 years).
      Made in 1986 a *big* mistake on the hardware side with a 16bit dual ported ram between a 80186 and a 8051 (endian problem) and it needed a byteswap what costed 400 uSec for every word, and yes i had done that on a other board the correct way, but production was already running :(

    2. >if you can’t express yourself well on paper, there is no way you are going to be able to create coherent, maintainable code<

      Somewhere along the way I heard, and adopted, the phrase: "If you can't describe it in a sentence, you can't code it."
      While a bit extreme, there's wisdom in the concept

      1. Ages ago I had a small project (DOS TSR, mouse driver for ELO and Microtouch monitors). Wrote API for the rest of the guys (int 0x33 or what was it, added 4 point calibration etc) and user manual first (I had time!).
        After that code practically wrote itself.

  4. Bravo Sierra. All of my employers and clients have had engineers that do both; probably because they were all mid-size to small organizations. For most of my projects, completion of hardware design was after the code was done. And people with only CS educations are pretty much worthless in my neck of the woods.

    Where software does not control a safety-critical function, hardware will always take longer to complete: safety and EMC and environmental problems frequently cause another design spin.

  5. Q: How many software devs does it take to change a light bulb?
    A: That’s a hardware problem.

    Q: How many hardware devs does it take to change a light bulb?
    A: Tell software to code around it.

      1. THIS 1000%. In my Career, it has been this way: The hardware and Software guys come up with a working solution, that fits the application, works well, and is inexpensive to produce, then marketing or sales gets involved and totally upsets the scope of the project ion order to meet the demands of some fringe application, or because they want some ‘buzzword’ or ‘feature’ they can use to beat the competitor over the head with. but has no real application or value, and double the cost or complexity of the project.

        1. My experience with sales is similar … “fish … we could sell billions if only they were ducks” …
          How about selling something that works, passed QA and got certified instead?

  6. Give how much has moved from hardware to software in the last 30 years – ie a dedicated circuit now replaced with a cpu with things hanging off it – the old (if it was ever true) 90% done when the hardware finished is dead.

    There still a lot of work to do with the hardware, but assuming the hardware works it’s the software that will make or break your product – and I often find it hard to believe the lack of work people put into it when they did so much work with the hardware..

    Mind you, software guys can be just as bad with the next thing up the chain – documentation.. I’ve seen people spend thousands of hours on a software project, then an hour or two on documentation – and as a result just about nobody uses whatever they have written..

  7. We can all stand in our bunkers and hurl hand-grenades at the other side. How much better to encourage intense co-operation between the s/ware and the h/ware people from the earliest stages of the project, even from the concept design, even better from the first contact with the customer.

    Have the questions become more of the form: “we can do that in various ways: how you would like us to do that so that is easier for you?” No more of: ” We have decided to do it this way and already had it approved from above, so bugger off with your proposed changes!”

  8. It’s frequently portrayed as a fight but really its finding the right balance of hardware vs. software based on what’s doable and the cost (not necessarily only money.) In general, hardware is faster but harder to change and takes more money and time while software is slower but much more flexible and less expensive for the same functionality in hardware.

    The old joke around here of “using an Arduino for everything” vs. “it should have been done using a 555 timer” is actually a reflection of the different weights applied to the different costs in different kinds of projects. Many hobbyists, for instance, tend to use what is available on hand and generally don’t want to investment a huge amount of time and effort to get something working; hence, they use an Arduino since they’re relatively inexpensive, easily available, and easy to use. On the other hand, many consumer product projects tend to try to reduce costs as much as possible since a $2 Arduino in a product shipping one million units costs $1.5 million more upfront than a $0.50 555 timer.

    I do both software and hardware and both professionally and for fun so I frequently have to balance the two. I’ve chosen the “555” for a work project and the Arduino for a personal project even though the projects were similar. In the end the right balance is about minimizing your cost however that cost is calculated for the situation. As an “engineer”, learning both hardware and software will help you make that decision more wisely.

  9. Hardware will always trump software. Why? Because no matter what code you choose to write, ultimately it’s running on hardware and the UI is also hardware. Even if you are running something on a VM, that VM is running on hardware once you reach past the host server’s OS, and the monitor you are viewing with is hardware.

  10. What I truly miss is people taking pride in writing efficient software, now they just tell you that you need better hardware.
    Hardware has become so cheap and powerfull that noone cares if the software is crappy and unoptimized.
    Old eastern european coders used to write really good software, because they almost certainly had worse hardware then you to run it on.

    1. You are only partly correct. Yes, it’s important to write efficient code and yes, modern hardware makes it easy to be sloppy. But most of today’s compilers + today’s OS’s won’t even run on a 10 year old machine.

      If course there are acceptions. I still write, compile and run code on PIC chips. And some PIC projects come down to analyzing code for efficiencies just so it will fit.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.