Back to Basics
So here is another article from Joel on Software. In this article, titled Back to the Basics, Joel talks about the importance of understanding how some lower-level things (like how strings are stored and memory management) work. It’s a bit of a rant. His conclusion is that you need to have a CS background and/or deeply understand all these low-level things in order to be a good software engineer. If he were to write this today, he might be accused of gatekeeping. He’s definitely not wrong in that having that type of knowledge can be helpful. The question is, is it necessary?
Leaky Abstractions
The big issue he is addressing is the idea of leaky abstractions. Joel talks about strings. If you are a naive programmer, you might think a string is a string is a string. You can add or remove characters, concatenate 2 strings and everything should be fine. In an ideal world, you shouldn’t have to worry about how they are stored in memory. But at the end of the day, a string is just an abstraction for a series of bytes. And that abstraction leaks.
How a string is stored in memory can affect a lot of things. Joel points out how null-terminated strings can quickly cause problems when you want to concatenate a bunch of them. There’s some overhead there that doesn’t scale well. So you try to concatenate a bunch of strings together and suddenly your performance tanks. If you don’t understand how they are stored as bytes, and how the concatenate algorithm works, you don’t know why. That’s the leaking of the abstraction. Something that really shouldn’t matter ends up having an effect.
How deep do you really need to go?
The question then morphs to “How deep do you really need to go?” Do we really need to understand all these low-level details? That’s a tough question. I think having some understanding is useful, particularly when you run into problems. It gives you an idea of where to look.
How does that apply to LabVIEW? Well, I saw a presentation by Darren Nattinger on optimization. Basically, he said “make it work”, then make it faster if you need to. I think he nailed it. With today’s computers, a little inefficiency is generally not a big problem. However when it is a problem, understanding a little bit about how LabVIEW manages memory and data copies, and the in-placeness algorithm, the root loop, and few other common bottleneck areas can be very useful. These are things that 90% of the time you don’t have to worry about, but you should definitely be aware of them.
Life is Abstractions Built Upon Abstractions.
Life itself is nothing but a series of abstractions. The truth is that our world is really complicated. It is impossible for us as human beings to understand it all. So we don’t. We create abstractions which are really just generalizations that allow us to ignore a lot of the inherent complexities of life. And we nest these on top of each other.
Let’s step away from technology to something we are all familiar with: Cars. Steering wheel, brake pedal, gas pedal, speedometer – that’s all an abstraction. It allows us to get into any car (or truck) and be able to drive it, no matter what type of engine or suspension it has. It could be a F150 or a Subaru Impreza. Doesn’t matter. If you understand the abstraction, you can drive it.
But even that abstraction leaks. An Impreza accelerates much faster and has a different turning radius than an F150. If you switch from one vehicle to another you probably want to know that. Look at steering. Turn the steering wheel the car turns. Or at least it should. What if you have bald tires, or are on an icy road. The abstraction quickly falls apart.
Always check your assumptions
As an engineer, I learned all about abstractions in school. They weren’t called abstractions though. They were called assumptions. We’d learn some really complicated equations, with tons of variables. Then the professor would say “Well if we assume there is no friction or air resistance” or “If we assume that we stay within this linear region, then we can use this simplified equation.” That simplified equation is just an abstraction.
When I worked at Westinghouse we went through a period where they were encountering a lot of defects and errors. They did a study. They figured out that the number one cause of all their problems was not validating assumptions. People would just assume that the pressure and temperature would stay within the limits and we could use the simple equation. Unfortunately like turning the steering wheel when you are on a sheet of ice, things don’t always work out as planned when you operate them outside the optimal conditions. The abstraction leaks.
So what does all this mean? Well, I think it means it helps to know the boundaries of your abstraction. Know what assumptions you are making. It’s worth validating those assumptions, particularly when you are having problems. Knowing what those assumptions are and if they actually are true, gives you a place to start looking when you are troubleshooting. Also staying away from the boundary conditions can help you to avoid problems in the first place.
