Hardware or Software?

Picture this. You’ve seen a thing on the Internet. Someone has made something. It’s cool. There’s a fritzing diagram and the source code on github. You want to make the thing yourself. You collect the parts needed to reproduce the thing. You study the diagram. You hook everything up carefully. You run the software, and, and, nothing. It doesn’t work. Why, dammit, why?

Before you turn to StackOverflow, or submit a bug report, you need to collect information about the problem you’re having. But how? Where do you start? What can you do?

In days of old if something didn’t work when hardware and software were brought together the first step was to decide if the problem was hardware or software?

If I had a dollar for every time I witnessed a conversation that went something like “It’s not a hardware issue, it’s software” and then “no, the software works, the problem is hardware” I’d have about $219. This is natural when two teams of specialists develop their own part of a system in isolation. The hardware team, with CAD, soldering irons, data sheets, wires and duct tape. The software team with star wars figurines, design patterns, coffee,  and clack-ity keyboards. Both teams developing according to their understanding, not really ‘getting’ the ‘other lot.’ Both teams remember that meeting they had early on in the project where they got together and decided who would do what, the division of labour, do this bit in hardware, this in software, good, all sorted, see you in a few months with a prototype. Then, a few months later, the teams get together again for ‘integration.’ Lets have it then. Software loaded, smoke emitted, heads scratched. Factions form, alliances struck, tempers fray. “hardware’s fine, it’s your software that’s broken.”

You can argue about what’s broken until your company goes bankrupt but that does no one any good. It’s more productive to try and figure out what’s going wrong. You may have your theories, but theories don’t pay the bills, what you need is proof. How do you get this proof?

It has been my experience that when something doesn’t work, whether you’re a lowly cog in a team of hundreds, or a one person team working on your era defining invention, your life will be much more fun if you know how a little about electronics. With a little knowledge of electronics you can help find proof, and you can understand the proof found by others. With trivial problems like “the LED doesn’t flash” you don’t need to know too much to figure out what’s wrong. As your system gets more complicated, your knowledge of electronics needs to develop. Luckily for you, as a professional software developer, you already have a lot of knowledge that you can apply. You see, fault-finding electronics and testing software are the same thing.

Wait, what? No! That can’t be true. Testing software is not the same things as fault-finding electronics.

Well, sure, not exactly the same thing, but close enough to be analogous. Here’s the analogy. Fault-finding electronics is like testing software in that you find interfaces, and measure what’s happening at them.

In hardware, just as in software, if you want to test something you need to find a place you can test. In hardware, just as in software, there may be things you don’t have access to, e.g., you can’t test what’s going on inside an IC but you can test its interface, where it connects to something else. In hardware, just as in software, you need to learn to use some tools to help you test.

In hardware, test tools are often physical devices. The most basic is the voltmeter. It, as it’s name suggests, measures voltage. It’s so simple a tool that you’ll have a hard time finding a voltmeter that doesn’t do other things, like measure resistance and current. These are known as multimeters, they are ubiquitous devices in the world of electronics and if you are going to be doing any sort of hardware project then you need to get one, and learn how to use it. You don’t need a flash or expensive one. My one was probably the cheapest around at the time I bought it, it was so long ago I can’t remember. My total investment in that multimeter has been in the region of $0.75 per year. It’s outlasted the company that sold it to me.

Buy a multimeter and learn how to use it.

The cheapest available at the time

With basic knowledge of electronics and how to measure voltages you can see exactly what’s happening in your circuit. When you can see what’s happening in your circuit you can deduce where the problem is. Hardware or Software? Elementary.