"Software Engineering Explained"
This is good for a laugh.
Posted on 03/05/2008 2:54:12 PM PST by rabscuttle385
You're right. Software engineering, however, is not. And, having started (and dropped) a course on object-oriented design (with design patterns), I can tell you that software engineering is not a joke. The FReeper who called it "extreme" is right on the money.
That said, it is important to have business acumen. Too many mistakes were made during the dot-com frenzy by tech people who knew nothing of business, and vice versa.
And, those "programming concerns" you speak of: we computer science folk learn the "why" of data structures, computation theory, object oriented design, and algorithms, not the "how" (that's why we have programmers).
A technical school programming course is as good as a CS degree from any college or university.
Yes and no. Those sorts of courses teach one or two of the latest languages. Technology dies quickly, but the theory behind it (which is what a good CS degree will emphasize) will live on for far longer.
The CS folks are the architects, engineers, and scientists. The programmers, IT folks, and business folks are still important though; they make our theory come alive and bring it to market.
"Software Engineering Explained"
This is good for a laugh.
Maybe that happens with the larger organizations. However, there are still smaller firms doing "low level" programming of customized applications and systems, right here in the USA. You don't seem them very much; they are mostly behind the scenes.
Exactly right. This is the place where a system will succeed or fail. A system that has complete specifications and, more importantly, a concrete list of deliverables will almost always succeed. That list has to include specific acceptance tests.
The biggest problems arise because the business types don't understand the importance of things like RAS, upgradeability, and user training. These things are usually more important and more costly than the function that is being addressed. The CS people don't usually know enough about the business to develop this part of the requirements on their own, and even if they did, they don't know enough to make a convincing argument about why the system should cost 3X what the basic function would cost.
Even if there weren't offshore companies that would bid just the cost of the functionality without all of the system concerns, there are plenty of software shops in the US that will.
There's an old saying - "you get what you ask for". There are many fine CS people who can deliver what is asked for. The trick is finding people who know what to ask for. CS courses teach you the former; that's the "easy" part.
The CS folks are the architects, engineers, and scientists.
The theories don't live forever, either. With every upgrade in hardware - size and speed of any storage device; networking capabilities; etc.- the CS theories need an update. And those upgrades come fast - every 3-5 years there is a major upgrade somewhere.
The CS folks can only do as well as their specifications allow. And even companies who do their own development in-house won't give the CS folks free rein. Some of those do, however, teach some of the CS folks about the business so that they become part of the specification development process. That's not typical, but it does help to get better results.
No theory lives forever, but some live for a helluva long time. Trust me, for example, the results of the Halting Problem will be relevant for a very, very long time.
I suppose I should have made a distinction between research and system development. You are absolutely correct that there are theoretical problems that
are of ongoing interest to CS researchers. You can go back even farther than Turing to find interesting theories.
But until these theories result in practical applications, which is almost always dependent on some advance in hardware, they are only of interest to researchers and academics.
The majority of CS people work in some system development capacity, not in research.
They don’t know me.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.