Abstraction Is For Both Humans And Software, But Not Software
Filed Under Thought Stuff
It is funny how software engineers always tend to simplify problems with one additional level of abstraction; that is, the answer always lays in the next tier of thinking.
The original Von Neumann computer did not have CPU registers, and when Von Neumann was asked he responded “Any competent mathematician will be able to keep track of them in their head”, and as you can imagine CPU registers became the first level of computer abstraction. Then came the primitive data types, the first procedural languages, and then the grand daddy of them all OOP.
With concepts such as inheritance and polymorphism, there is no question why today’s software developers think and solve problems at such a high level. Don’t get me wrong – this is a great thing as it allows us to concentrate and be more efficient on solving real world problems. However, this has also become a very bad thing as the majority of us no longer understand how the basic computer works.
Humans (on a daily basis) do not look at a piece of fruit and say to themselves, “Oh my, that mass of molecules sure looks tasty”, of course not. This is because in order to function in our space we do not truly need to understand that level of detail.
However, in software we both do and do not need to understand the lower levels of abstraction for the software to work, and this is where we as modern software developers are getting soft.
I have met many young (and talented) developers that have never programmed in BASIC. Never even developed in C or C++. Have absolutely no clue what a semaphore lock is. With first languages now being Java or C# the days of algorithm analysis are withering away.
I guess what I am trying to say is, you can be the best orange farmer on the planet without knowing anything about molecular structures, but you can’t be the best software developer without knowing how your CPU works…
10 Responses to “Abstraction Is For Both Humans And Software, But Not Software”
[…] Abstraction Is For Both Humans and Software, but Not Software (Max Pool) […]
Look no further than Google Chrome for an example in how understanding the underlying levels of abstraction can give you an edge in software development. They sat down an tweaked their code for the precise environment it is running in, and managed to deliver a browser that loads pages twice as fast as Firefox.
It’s great to have all the modules and such that the extra layers of abstraction provide in Firefox, but it is no competition against a simple browser that is as fast as lightning.
You’ve kind of dropped the bar way low here.
You’re saying that someone should think about the molecules. 😮 WTF. Of course we won’t. And we’re not going to test the acid levels on every piece of fruit.
And I’m not going to think about how every electron flows through the circuits of my computer, it would just be stupid :). N’or do I think of the I/O reads my computer does to read a simple file.
But I do get your point. It’s scary to think that in a couple of years you’ll be talking with someone that comes in for an interview and he’ll say pointer-who ? Or Merge-what ?
Also there is a shift toward web based apps and people won’t care about how the CPU works they’ll be happy knowing how to do their job. And you’ll be thankful when someone that knows the basic of HTTP 😉
A few comments on this…
First, registers are not an abstraction. If anything, they make life more difficult. They improve performance by reducing instruction size and holding data that will soon be used in higher speed storage. They don’t really abstract anything. It would be much easier to program in assembly if you could just directly refer to memory locations.
Second, do you *really* understand how your CPU works? Do you understand how it takes apart instructions and schedules the use of processing units, often out of order? Do you understand how cache architectures works? Do you understand how synchronization instructions interact on the memory bus on an SMP system? Do you understand how interrupts are routed to processors on an SMP system?
You may understand these things, but very very few software people do. I have to know about them since I work inside a kernel, but the really low level details belong to compiler writers and processor designers. The “CPU” as most software people know it is an abstraction on top of something quite different.
Third, I don’t see what algorithmic analysis has to do with languages. You can do algorithmic analysis in any language.
As far as your premise, I used to think that way also, but I’m no longer so sure. Perhaps understanding the details a level down from where you work is useful, but if you go to far you will be buried in too many details.
I *do* think that teaching and doing algorithmic analysis is a good thing because of how it trains your brain to think. You may forget how a quicksort works, but the training that went into understanding it stays with you. And knowing the various tradeoffs of tools you choose is probably a useful thing, too. But understanding how superscalar architectures work is probably not useful to the average software designer.
@Mihai @Corey –
My intent was not to suggest that everyone needs to know everything about everything, as that would just be foolish. But I would suggest that we as developers need to know at least high level details of what we are working with.
I do not think it to be unreasonable to want a new hire candidate to understand the basics of HTTP requests, even though it maybe abstracted away in some web framework. Likewise, I do not need them to know every detail of the hardware that they use, but the answer “I have no clue” when asked how a CPU works is unacceptable as we don’t develop on magical glowing boxes.
I am not suggesting the bar needs to low, but I am suggesting it shouldn’t be high enough to walk under.
[…] Abstraction Is For Both Humans And Software, But Not Software – Max Pool ‘ It is funny how software engineers always tend to simplify problems with one additional level of abstraction; that is, the answer always lays in the next tier of thinking ‘ […]
I agree completely!
Developers need to have a basic understanding of how a computer functions in order to design efficient algorithms.
In the past I have had to explain that computers like NUMBERS and not TEXT to these type of developers.
Anyone with a fundamental understanding of a computer knows “Numbers are more efficient because it’s less bits across the bus”.
Just as a mechanic needs to know how an engine fundamentally works to fix it, but they DON’T need to know how to design an engine.
A developer needs to know how a computer fundamentally works to program it, but they DON’T need to know how to design computer hardware.
Who frankly cares about basic, c or c++? seriously, who even cares about pointers? a good programmer needs to have to know where the objects or data “live”. but appart from that there is more performance to be gained by understanding parallelism than pointers or deeper cpu archs. because on average the compiler usually is way smarter when it comes to CPU optimizations like pointers, etc. what the compiler can not do is finding effective parallelism (yet?) and effective algorithms. But that’s true in any language.
And “best programmer” is highly subjective. personally, i’d rather hire a programmer who knows how to program DEFENSIVE code and with respect to multiple threads than one who knows the last optimizations on single core machines. And the fun part is: Doing “parallel” right requires more knowledge of algorithms. Simply because parallel algorithms are a superset of linear ones.
So to sum up, I don’t know if it is correct to deduce little knowledge about algorithms from any kind of programming language preference or knowledge about CPUs and pointers. 😉 And from my point of view a defensive programmer who knows about multithreading is better suited for the future. Because the future simply won’t be about single core optimizations.
I agree and disagree with the author. I’m one of those programmers who only knows bits and pieces of how the machine works and does understand some of the basics of HTTP (I do know the most of the error codes SUCK!)
First off, companies do not invest in their employees! I have met SO many computer science majors who are not working in a computer related field. Why? Some decided to do something else.
Most just never found that rogue developer group job I did. In that group, the boss knew we spent half of our time learning and trying different things. Why don’t most companies insist their employees spend 2 to three hours a week learning something new and reporting back on what they learned? I have lit a fire under my own ass and learned what I need to know and even things in computer science that are interesting to know (I’ve started working through a book on Assembler).
Quality software DOES not necessarily get built by those who know the machine like the back of their left hand. I’ve seen it more than once. I know a guy who is fluent in C++ and wrote hardware drivers for Microsoft, but would introduce a bug into nearly every patch build I tested when I was still in QA! He understood all the concepts, but when he sits down to code he does not TEST!!! Why don’t developers test? Lots of reasons, including our overly accelerated market place, but some of them are developers fault. When I’m programming, I always test my stuff. And you know what? When I do that, it WORKS! I love the TDD revolution. It is not a cure-all, but developers should fully embrace it as an essential part of building software.
We should know the basics of the machine and the software stack we stand upon. I am attempting to correct that fact about myself. It’s slow going, but I find it very interesting. However, just knowing that will not fix software. We need to TEST our code and our SOFTWARE (QA engineers unite!) with both automation AND manual verification. And the industry needs to embrace these things as necessary parts of the SDLC.
Regards,
Sam
Some of the best books I’ve come across on this very subject are the “Writing High Level, Thinking Low Level” series. They basically disect this very topic.
It never ceases to amaze me how many “expert-level” programmers never consider the effect that optimzing compilers may have on their code. There are many ways of writing high level logic that make it easier on compilers to squeeze out every drop of performance. Without the lower level knowledge, one is blind to such issues.
The question I continually hear when this subject comes up is, “Isn’t better to write correct code than performant code?” Well, the answer is, of course, it’s important to do both.