How much should a "software guy" (or "software gal") know about hardware?

Question

Aside from the software developers working on embedded systems and hardware modeling or any other job that deals with software for or on hardware, how much should a software engineer know about the underlying hardware that they might be developing for? Should it be treated as a black box that just works or should there be a very strong working knowledge of the hardware systems?

EDIT: This question was inspired by this post.

Answer 1

If you have absolutely no idea about the basic functions of a CPU, single/multi-core issues, L1/L2/L3 caches, relative speeds of cache/RAM/HDD, you can function as a software engineer -- just not very well. You'll do silly things based on silly assumptions, and you'll never be able to be proficient at optimization.

Answer 2

The more they know the better IMHO. However, at a bare minimum, a developer should have a rudimentary understanding of how the CPU works in regards to that it cycles and executes instructions etc... Also having, a basic understanding of how memory works especially in relation to variables is a must. Basic knowledge of storage and I/O is a must as well.

Answer 3

It depends on the job the programmer is supposed or expected to do.

There is no fixed answer, but as a general rule, the more the better.

Answer 4

So from my understanding from Stu's and Daniel Auger's posts a knowledge of how the CPU works (although maybe not specifics), how RAM works, how file writes are written to the HDD, and that kind of thing are good to have, but you might not need to know about form factors, chip sets, and so on.

Answer 5

The more you know the better. You can do programming treating it as a black box, but you'll write betters software if you know what's going on.

Well acutally, after thinking a little more aboyt it I'd say, taht there are some things that you have to know about HW. For example you probbably can't get away without understanding that harddrives are a lot slower than the system memory, but in most cases you don't have to care that system meomry is slower that CPU registers.

Answer 6

It depends on your role really. If you are writing line of business applications its unlikely that you will need to know about specific hardware (Especially if your users are all on the same kit). However if you are writing a product to be distributed externally be preapred to find out that your software will not work a specific version of a grapics card in a sony vaio running a debian distro.

Answer 7

The truth is that Shlemiel the painter's algorithm is usually fine in 90% of the cases out there (warning, numbers are pure conjecture). If you what makes understand run-times faster or slower (even if it's just intuition for the most part), Big-O notation, basic algoritmic design, and so forth, you're set for a very large proportion of software.

Answer 8

I personally think that there are at least 3 aspects of hardware that a software engineer and even a web developer should know about.

1. Memory(RAM); You should know how memory is mapped to hardware, how that memory is allocated to primitive types of the language, as well as how the data structures, such as an array or hashtable use it
2. CPU and threads/processes: I think this is really important to understand. We're moving to a multi-core environment and making the best use of threads and processes is crucial to the performance of the application; Also, knowing when to use a thread and when to use a process
3. Swapping: Eventually, for one reason or other, an application will run out of available RAM; A software engineer must understand what happens then and how that affects the application;

There are a lot more interesting topics about hardware to learn, but I think these three things are a must.

Answer 9

I really believe it depends on what type of software engineer the person is. Ideally, programmers should know everything about the machine, but in reality this just isn't possible. I think knowing the basics is important for everyone, even though everything isn't necessarily applicable in all situations. I place knowing about hardware in the category of "things that might get you out of a sticky situation," but I think the real reason to learn about hardware isn't directly related to software development. Unless you are in a large organization where the roles of network admin etc. and software development are strictly segregated, you'll probably be thrust into a situation where you have to solve a hardware problem even though it technically isn't part of the job. It could mean the difference between going home at 7pm and 7am the next day (or in some situations even keeping your job). Not to mention the fact that it helps being able to justify why the software you right needs to have certain hardware specifications. (Why are we spending an extra 30k on a 64 bit server again?)

Answer 10

As a long time corporate developer having to work with many vendors on the applications that we interact with I believe it is very important to have some fundamental understanding of your target hardware.

Virtually every performance problem that I have had to work on is a result of the developers not understanding their target environment. You need to understand what your application is consuming and where it is vulnerable to bottlenecks. The same goes with the database resources that you are consuming.

I don't think you need to know the differences between cpu revisions or things at that level, but there are many performance metrics that a developer should understand.

The time to learn is now (the learning never stops) and not when you have deployed an application and it doesn't perform in your client's environment.

Answer 11

I think every programmer should know the basics of system architecture (that is the design and functioning of processors and memory).

There is a good series of articles on LWN about these subjects, I'll link to the first article which contains links to the rest in the series: http://lwn.net/Articles/250967/

Answer 12

This is the Karate kid solution: Wax on, wax off.

Read an copy of Rodney Zak's "From chips to systems" (amazon secondhand?)

Now think deeply about the difference to modern hardware

• a factor of a several thousand for the CPU.
• a factor of a few hundred for RAM.
• Cache is faster than RAM, but slower than CPU.
• Disk is about a thousand times faster than it used to be when Zaks wrote the book.
• Cores are not quite additional CPU's.
• more cores are even less so.

(Mopping your brow at this point is OK)

Now knock the head off the EE that tries to do the EE equivalent of fizz-buzz on you.

Hai!

(And the great part is, you still can't fix your cousins computer.)

Answer 13

I'ved just enjoyed reading a couple of blog posts regarding this subject:

• Infrastructure appreciation for developers
• A developers guide to storage