General IT ManagementDiscussion of challenges facing IT management including articles published throughout the Earthweb IT Management network at Datamation, eSecurityPlanet and CIO Update.
Who Killed the Software Engineer? (Hint: It Happened in College)
A prominent professor says that university computer science programs deserve a failing grade. Today’s U.S. grads are not prepared to compete in the global high tech market.
I agree whole heartedly! Before I retired 10 years ago, I had great trouble finding and hiring qualified software engineers. I was an outside IT director for a company that designed and produced hardware and software for commercial and military satellites. The problem existed then and it is worse now.
In my view, this article is drawing some far-reaching implications from some fairly simplistic starting points. As a friend of mine once summarised: "some of the things that we ask software engineers to do are equivalent to asking a metallurgist to design a motor car".
Computer scientists are not necessarily software engineers; software engineers are not necessarily IT system designers; and there are variety of other disciplines involved in providing systems of any real use and complexity.
The business of IT system development is, and has for a rather a long time been, more involved than expecting an expert computer scientist to provide your company's ecommerce system. Of course, this does not prevent many organisations from continuing to have such expectations!
I certainly agree that we are at risk of devaluing changes in higher-education:
(1) "dumbing-down" courses simply to reduce attrition,
(2) focus on short-term, entry-level skills simply to satisfy demands of employers,
(3) lowering standards in response to a culture that regards a college degree as a right instead of an achievement.
However, to pitch the message by singling out an individual programming language or course is at best flawed promotionalism and is at worst the same oversimplification that is the root cause they should have addressed. Our culture is too fond of no-effort diet pills and 15-second sound-bite analysis of complex international issues. I would expect university professors to exemplify careful analysis and a willingness to raise the hard questions.
Instead, the issue is clouded by unnecessary scape-goating.
I had a discussion once about this subject matter with the program chair for my alma mater’s Computer Science department. He told me he was aware of the shortcomings of today’s CS grads but … like all schools, our’s was accredited. If they included the coursework to make CS grads ready for the ‘hit the ground running’ (in addition to all the coursework required to meet accreditation req’s), it would take six years to obtain a BS.
That being said, I don’t think the required skill set can be taught anyway. Too many derivative frameworks to choose from. Nothing in the world substitutes for OTJE. If businesses are complaining about the lack of IT/IS talent coming out of today’s colleges, they should lobby congress for tax breaks in exchange for hiring such people – to offset the cost of training a new hire Software Engineer.
I think a key issue here is that the definition of Computer Science has become somewhat fuzzy. There are now a number of different aspects of computing that one could choose to focus on, and each has its own unique elements. I think this professor is talking primarily about Software Engineering, which is in fact somewhat different than what I think a "pure" computer scientist tends to focus on. For example, a computer scientist might be interested in computational theory, which is concerned with the fundamental capabilities of computing machines, or complexity theory, which involves determining how computationally difficult a problem is to solve.
A software engineer, on the other hand, is more interested in the practice of creating software systems using a set of realized computing machines. Software engineers take advantage of the body of theory developed by the computer scientists in order to do their job.
What this professor is saying is that rather than turning out competent software engineers, we are turning out marginally skilled computer programmers.
A software engineer must be a computer programmer and a whole lot more. The word "engineer" in the job title says it all - they must not just understand how to write software, they must understand the system that underlies it, including the logical organization of the hardware. A good engineer also understands design issues such as risk assessment, how to make tradeoff decisions, consider performance and scalability, generality, etc. They must also be quantitatively oriented and have a good mathematical grounding in combinatorics and statistics. In other words, they must have many of the same basic skills as an electrical or chemical or civil engineer. And oh yes, they should be able to communicate effectively (a skill that is sorely lacking).
Is this problem limited to recent CS program grads. I think not. I recently had a programmer with many years of experience that I let go because he couldn't think beyond cobbling code together. On the other hand, I have a young CS grad who thinks and acts like an engineer and has been a terrific addition to our team. So obviously not all CS grads are poorly educated - I think a lot of the courses are there if they want to take them.
One thing I think every CS program should insist on is taking several courses in machine language, compiler design, and perhaps even logic design. Many programmers are completely lost when their code crashes - they have no clue what the underlying problem really is, and are poorly equipped to troubleshoot it.
Perhaps part of the problem is the splintering of the CS curriculum. It seems that most schools now offer different "tracks" - you can focus on IT, for example, which is a very high-level system view that eschews many of the details of hardware and software systems, or you can go the more intense software engineering route. However, the IT students I have talked to can seldom describe what Internet Protocol is, for example, or how it is different from Transmission Control Protocol or User Datagram Protocol. How can you hope to troubleshoot networking problems if you don't understand how the fundamental underlying protocols work???
This dispersion of the students into different strata is watering down the requirements and letting many skate by with only superficial skills.
I was doing some HTML layout yesterday with CSS (I'm not really a web programmer) and suddenly realized that I was googling certain topics, finding pages which were full of pitfalls for doing this stuff. It suddenly hit me that programming has now become a matter of knowing all these silly pitfalls and side effects, rather than applying good software engineering practices. Thus today's programmers are geared towards this and interview processes are more about finding out if you have knowledge of some silly little point, rather than having regard for your depth of experience and breadth of knowledge.
Pitfall programming is not new though – it was firmly embedded in most C-based languages, especially C++, which Dr Dewar seems to hold up as good example. On this point I disagree with him. I even wrote "Objects Unencapsulated" in the 1990s decrying what had happened to object-oriented programming. But the book wasn't popular because it outlined principles and consequences (apart from criticizing a revered language).
Perhaps the decline started in the 1970s when Burroughs gave way in universities to Unix. Hence we went from machines with the best stack dumps ever to rather weak ones in Unix, we went from ALGOL as a systems programming language with automatic detection of overruns (and resulting stack dump) to C with buffer overruns, and consequently viruses and worms. We went from machines with a well-defined architecture based on computer science principles to the "let's have fun and patronize people's egos" problem that Dr Dewar sees. I can't blame universities for the adoption of Unix - it was available, whereas Burroughs technology was blocked by the Burroughs sales prevention force. The architecture of these machines should still be studied (despite what Hennessy and Patterson say).
Why - because Burroughs machines had a lot built in to remove or automatically detect pitfalls so that programmers could actually practice software engineering. A more modern example is the object-oriented Eiffel language, but disappointingly programmers actually seem to prefer being tech-geek nerds who are able to remember thousands of pitfalls, rather than those who can apply good principles.
I take the long term view. In the 40's and 50's, computer scientists were lucky if they could flip switches to enter binary data into a computer - no tapes or punch cards. When they got tapes and punch cards in the 60's, they could boot the system from a tape and run a program by stack and loader deck on the front of the job. Then disk drives came along and eproms and those would boot the system and NOBODY CARED ANYMORE about flipping switches or running paper tapes. Well, actually, somebody cared - but it wasn't the young computer engineers. Then microchips reduced all the complexity into invisible little chips. What happened to flipping switches to enter binary boot code into the system? We forgot how to do it - and guess what, there are more computers running more programs now than ever. My students write more programs in their first week than I wrote in an entire semester of my first comp sci course. Nobody is trying to record programs and cassette tapes like we did with the Radio Shack trash-80s in the late 70's. I still have a box of floppy diskettes on my desk - I pick one up whenever I need a warm fuzzy feeling of security. But we don't have any floppy drives in the lab.
We've come a long way, and a lot of technologies have become obsolete and basically meaningless. They were interesting then, and they are still interesting from an historical standpoint. But I don't think we need to start off new computer science students at the bottom of the ladder, flipping switches. Fact is, the students simply won't accept it. Am I pandering to their laziness when I teach them how to code GUI interfaces in Java (we do code them - we don't use a GUI design tool)? Am I racing into an uncertain future when I give them modern tools and modern problems to solve, instead of coding a quick-sort in assembly language?
I don't believe the future is that uncertain. And I don't believe that low-level, "close to the metal" programming is going to be performed by the software "engineers" that are apparently disappearing. Indeed, software engineers should probably learn more about design and system interface issues than electronic engineering and hardware drivers. As systems get larger and connect more and more components together, we aren't even managing to write software that takes advantage of multi-core CPU technology - we don't have useful tools for parallel processing. I talked to a software engineer at the European Space Agency and asked him how many people are still programming in assembly/machine language for the equipment on their space probes. He said "virtually none - the low level stuff is all done - most of our programmers are writing code in Java". I was pretty surprised.
My take on Java is that it isn't "too easy", but rather too DIFFICULT for beginners. If Java and C++ and "Visual whatever" are the languages being used in production environments, then they probably are not appropriate for "beginners". I'm not a big fan of Scheme - maybe Logo or Alice or some other "eye-candy" is a good starting point. Java can come later. And if we actually still need C++ progammers 10 years from now, I imagine that experienced programmers will figure out how to write code in that language. If it were true that the "first language" has lasting effects, we better take all the PCs away from the school kids before they "wreck their brains" using easy tools.
It's not the specific language that matters anyway, but the general concepts. Booting up is a similar concept whether it involve flipping switches, using a floppy diskette, or relying on ROM and hard-disks. Arrays might look different in Python than in Visual Basic, but the basic concept is the same. If you don't understand OOP, you won't be able to program in an OOP environment no matter how helpful the IDE is.
Concentrate on the general concepts and use the best tools available. The tools are going to disappear anyway, so it only matters that they are good at the time. As one researcher said, over half of the "knowledge" that Computer Science students learn during college is obsolete before they graduate. If that's true, then it's not the right knowledge. If they are learning the names of Java class libraries and that counts as knowledge we really have missed the point. But that doesn't mean we should throw out Java - rather, give assignments that address the real issues (Big O and NP completeness are still issues). Just DON'T GIVE assignments where the solution can be "cobbled together" from existing classes.
"If people come out of school and they know Java and Web programming, and they know how to put things together from libraries, that's just the kind of skills that are not going to be [in] demand,"
Well, if they don't know this stuff, they're NOT going to be in demand these days. A good craftsman makes full use of their tools. Basic software engineering principles argue against the development of a system from whole cloth when components and tools are available that will increase the productivity and quality a hundred fold. This nostalgic yearning for the old days - typically expressed by faculty who are nearing retirement age and haven't bothered to maintain currency - is nothing but a failure to accept that their knowledge is no longer a valuable asset and of little interest to others except academics and the handful of vendors who still work in applications requiring low level access to the machine.
I couldn't agree more. An understanding of Assembler, knowing what a stack is, writing a basic compiler, understanding what's going on down at the metal used to be an essential part of being an alpha geek (a title I take great pride in). The ability to design a system, not just cobble together little packets of pre-designed code, not to use code writing systems (like the visual languages), heck, being able to write within memory limitations are all essential parts of being a software engineer.
I suppose we can attribute many of the web-based applications problems (security and otherwise) on this lack of knowledge.
We still need those CS people to write micro code, hardware driver code, bios code, ...
Those are all close to the metal and those are the pieces of code that are problematic in today's environment.
Try and find Win2k3, Vista or *nix 64 bit drivers for the TPM chip module or RFID devices.
Lack of these pieces of code have stopped many system implementations in their tracks, my own included.
Software Engineers vs. Computer Programmer
Linear Mode
