Computer Science Or Software Engineering
Computer Science Or Software EngineeringThis page is TooBigToEdit. Therefore, here are some stubs for factoring out the main points:
And now on to the too much text:
We would be much better off with good software engineering programs. There is certainly enough knowledge of architecture, problem solving strategies and design to form such a program.
This claim is based on a false dichotomy. How does someone know how to design and build a good application? Well, one must know something about the underlying components and algorithms. If you're designing an application with a database back end, the only way you're going to get scalable performance is if you understand, at a reasonably sophisticated level, just what it is that databases do. E.g. take the course or read Ullman's two volume opus or build one yourself or ... .
In addition, this seems to be making the claim that we would have learned faster if people hadn't mistakenly focused on Computer Science and instead had thought about Software Engineering. But what software engineering technique leads from BubbleSort to MergeSort? What software engineering technique leads from hand-coded parsers to context-free languages? What design pattern gives us better garbage collection algorithms?
Computer Science has progressed enough in the past forty years the we can now begin to develop the field of Software Engineering. This new field will either be based on a firm understanding of foundational CS concepts or it will be a worthless endeavor. -- WilliamGrosso
The discipline of SoftwareEngineering is doing what has already been done, far from the bleeding edge, and doing it quickly and cheaply.
I don't think things break up so easily into two categories (bleeding-edge and non-bleeding-edge). How would you classify something like Wiki? There's certainly no technical wizardry going on under the hood; on the other hand, it definitely wasn't yet another accounting system - and I doubt Ward's focus was on programming it efficiently. It seems like you need a separate category for it (and XeroxParc's work, etc.).
Constructionists like AlanKay and SeymourPapert would probably be horrified at the idea of splitting off programming from studying computations (SoftwareEngineering from ComputerScience). How are you going to think clearly about computations without playing around with a bunch of them? And how are you going to play around with computations without being able to program well (correctly, quickly, flexibly)? Whether or not ComputerScience is an apt name, do you really think we'd know what we know about it without actual computers to play with? -- GeorgePaci
Engineering can't exist before some basic theory is done, because engineering is the application of this theoretical background. Now the earliest engineering relied on work done in a haphazard way, primarily by the engineers themselves. However, the best method we know of doing this work today is called science (and mathematics, somewhat separately). A mechanical engineer relies on work in, for example, metallurgy and tensor mechanics; an aeronautical engineer relies on basic work done in fluids, etc. Without this work (most of which was/is done by scientists and mathematicians), the engineering field cannot exist, and for the most part the engineers do not do this work themselves. To see this, compare the literature in aeronautical engineering with that of fluid mechanics, and solution of PDE's.
With this dual nature in mind, consider the "Software Engineering" field. For the most part, the basic theory has not been done. There has been a lot of progress, and the people working on this are called "Computer Scientists". Notwithstanding the gains that have been made, anyone seeking to apply engineering methodologies to problems with computers can't help but run into trouble with our fundamental ignorance about computation. There are (almost) no steam tables for programmers.
It is a fundamental mistake to pretend that we can create an engineering discipline without the underlying theory. It is another one to pretend that "Engineers" can do this work. They can't, if they rely only on engineering training. So you either train them as "Computer Scientists", in which case they can't do engineering work (the current model), you train them as both (tricky), or you let them flail about in the theory without proper training. This last will slow things down a lot.
Perhaps, with the gains we have made since the 50's, we are ready to begin building a software engineering discipline. Those trained in it should be painfully aware of their limitations compared to their colleagues in, say E.E. programs - and how we can work towards improving that. They should understand why they need C.S. departments, and what they need from each other.
Of course, there are a lot of broken C.S. departments out there as well, but that is a different problem.
As to whether continuous study and self improvement in CS can lead to a significant improvement in the day to day activity of a software engineer. What I can say is that it works for me, I can't say whether it works for you and have no clue how it applies statistically to the whole population. In my practical experience, however, I've seen way too many people for whom the basic notions of CS that directly affected their work were totally unknown. People ranging from developers, DBAs, architects to successful and well respected book authors giving bad advice to others.
But what certainly happens in the real life is that SE done in ignorance of and very often against CS leads to objectively negative consequences even from a SE point of view.
Well, you said something I agree with. Namely: there aren't enough academic courses on software engineering. I'd go farther: existing CS professors aren't well equipped to teach software engineering and what they do teach is often woefully misguided.
I've had a running argument with a friend of mine who regularly teaches software engineering at a local university. He uses one of the standard big-tomes and covers all the material the intro says should be covered in a one semester course. And I regularly tell him that most of what he's teaching is hogwash and even the stuff that isn't, isn't the most important stuff to teach prospective programmers. That the best one semester course I could think of would be to focus on a particular type of system and walk through some implementations (say, focus on "database-backed web sites" and then go through a lot of the associated design decisions and have people explain how they built their real world systems. Or focus on "rule based expert systems" and walk through the literature, where people explain the various tradeoffs they make in designing and building such creatures. Or ...).
But then you went on to say "my point in making this page was just the observation while many students are busting their gray matter on push-down automata and Turing machines (which look like mathematical concepts to me)" and this seems to me to be precisely the wrong example.
Why? Because, for most students, these topics are covered in a one semester upper-division course on compilers. And that course is crammed full of useful information. From the theory of parsing (which normally also requires the students to write a parser using parser-generator which takes BNF-style input) to a student's first (and, in the vast majority of cases, last) exposure to hard complexity results to .....
At my school (http://cs.millersv.edu/), turing machines, push-down automata, and finite automata (including regular expressions) are covered as a sophomore in a class on computational models that is a required class for all majors. Most people didn't seem to get what the point was unless they had already had experience writing parsers (there was one sophomore in my class who WritesCompilersAsaHobby). -- JoshuaBoyd?
I've been programming professionally for 7 years. During that time, I've seen 4 (that I remember) hand-coded (e.g. somebody reads in the file as a huge string and then does lots of string manipulation on it) parsers. None made me proud to be a programmer. I've run into people who blithely assume that other modules are going to execute NP-hard tasks, I've run into "experts" on distributed computing (e.g. real-world programmers who put distributed computing on their resumes) who routinely misunderstand the problems inherent in distributed software (the better textbooks on the subject all involve a fair bit of mathematics), and I've run into people ....
What's more, I'm fairly certain that, as software grows more complex, we're going to need more sophisticated tools and concepts to manage it. For example: assertion languages. If you look at Eiffel, you see a fairly limited set of pre and post condition checks. If you look at R++, you see another fairly limited way of verifying conditions. Both the Eiffel and the R++ people claim to be helping the world build safer software.
But assertion languages are expensive. Sufficiently expressive ones contain undecidable statements. And even limited ones (like the two above) can contain assertions which are incredibly expensive to check. And this is especially true when people build their own (I've seen at least one project where there is, essentially, a constraint language for the database entries). I'd argue that such languages demand a programmer who is at least minimally versed in the elementary notions of formal language theory (e.g. the compilers course mentioned above) and perhaps a little bit of logic as well. If you can't tell undecidable from expensive from cheap, then you're woefully unprepared to use an assertion language.
Which is a long-winded way of repeating my point (claim 3 up above) and adding in "Yes, a Turing machine is a mathematical concept. No, a subject which uses Turing machines is not necessarily a mathematics course (unless, of course, you count all courses which use Integration as mathematics as well)." -- WilliamGrosso
"There is certainly enough knowledge ..." that if you put ten experts in a room, you'd get twenty-five answers (and two experts in intensive care). There is no industry / discipline consensus on what the right BestPractices are. Is it critical:
All I can say is that William and my experiences have been different. My undergraduate work was steeped in this stuff. Discrete Mathematics, Graph Theory, Theory Of Algorithms. Data Structures and Compiler Construction were tame compared to these. My master's program... Theory Of Computation I, Artificial Intelligence (which turned into an in-depth study of Horn clauses... skolemizing...), Analysis Of Algorithms. Perhaps my experiences are atypical. Not enough SE for my tastes. Don't get me wrong. I am glad that I've learned what I've learned, but I feel the pull elsewhere.
I do have to agree that some of the courses I would like to see more of are the ones William mentioned. Those which walk through real-life choices for various systems under development. Or, to respond to Paul, at least enough survey to make sure that students understand which development issues are under contention so that they can either aid the development of a solution some day, or recognize one when it comes along. Perhaps there simply is not enough time for such things. -- MichaelFeathers
PurdueUniversity has a SoftwareEngineering path, though they didn't call it that (and they admittedly had a lot of other cruft as well). I took CS, disliked the name, but was very glad I wasn't being taught by the engineers; they were so BigDesignUpFront it was insane. Not to mention, they loved documentation so much that taking an engineering course was a bureaucratic nightmare. The only good programmers I know who came from that environment switched to CS. They were D engineers, and became A/B CS majors. -- EdGrimm
Claim 4: We would have had the knowledge mentioned in claim 3 much sooner if people hadn't mistakenly focused on Computer Science and instead thought about Software Engineering. (Claim drawn from WilliamGrosso's post above...)
I'd like to remind you that Computer Science isn't limited to studying software. For example, at Swansea we have a final year undergraduate course about the foundations of VLSI design where students get to draw up some simple cpu cells and assemble them onto a bus. I think it's reasonable to put that sort of course on the curriculum, but it's clearly there to teach fundamental principles about hardware. It's not just a "background" or support course for a software-focussed degree.
Of course, most hardware people are likely to be drawn from EEE degrees... But I really don't think that CS and software engineering are or should be synonymous.
My degree (1983-986) was in "Computer Systems Engineering". It had its share of abstract/useless courses borrowed from Maths, Engineering and CS, but the main body of it was largely practical and detailed. For every course about group theory, laminar and turbulent flow, or Turing machines, there was at least one hands-on course on programming languages, solution design, effective use of databases and so on.
I don't know how many courses there are like this around, but I found it extremely useful. -- FrankCarver
During my PhD, some of us with work experience got together to teach a short course on how to program really. For example, my session was on SoftwareScaffolding? (test harnesses, that sort of thing). Over six lectures, we kept 1/3 of the class, which was pretty good for an unassessed class.
The issue that we wanted to address was that the programming aspect of the undergraduate course was too abstract ("compare the features of your favourite languages"). There was no mechanism for handling the apprenticeship side of learning to program. -- SteveFreeman
CarletonUniversity has been slowly introducing a software engineering stream under a Bachelor of Computer Science degree. So does OttawaUniversity?, its sister university.
The UniversityOfWaterloo in Canada just recently announced that the Mathematics and Engineering faculties will be jointly creating a "Bachelor of Software Engineering" degree program at the university. Previously Soft Eng was only an option you could take under either a Comp/Electrical engineering degree or a Computer Science degree.
too late for me (I'm out of CS and going into economics), but I think it shows promise...
-- StuCharlton
ProfessionalEngineersOntario?, the association for engineers in Ontario, and the Canadian-wide umbrella organization of such associations, CCPE (CanadianCouncilOfProfessionalEngineers?), have for some time been involved in battles and discussions with the universities about "SoftwareEngineering" programs which are run by the CS faculties and not by the Engineering faculties. The underlying issue is that graduates of the CS programs are not recognized as having an adequate academic background to allow them (after several years of work experience) to be licenced as engineers. Those graduating from the Engineering schools are so recognized.
On the surface, this looks like a battle over the use of the term "engineer" when applied to those who are not licenced by the associations. The provincial engineering laws require these associations to protect the public where engineering work is involved, and one of the ways they do this is to restrict use of the term ProfessionalEngineer and derivatives, which they generally define to include such terms as SoftwareEngineer. As a result, they are reluctant to allow CS departments to offer programs with the term "engineering" in their name, partly because of the potential for confusion of the public and the students.
Underneath this surface battle is some belief that CS programs don't provide adequate coverage of certain areas which are considered important to the engineering profession. Among these are an adequate exposure to issues involving SocietyTechnologyAndValues? (to use the name of one of the courses), such as whether certain technologies are used appropriately for the benefit of society. -- PeterHansen
ComputerScience, and SoftwareEngineering, while both misnomers in my opinion, are separate and useful disciplines. My perspective comes from my degree as a mechanical engineer.
What I have seen out of ComputerScience is that such a program teaches you how to make computers do neat and far-out things. Learning ComputerScience takes you that much closer to the bleeding edge of what computers can do. Such people understand algorithmic analysis (how to write an N-log-N algorithm rather than an N-squared one), crunchy topics like kernel development, AI, and high-end imaging stuff. They understand and do what the JargonFile calls "heavy wizardry".
SoftwareEngineering has very little to do with that heavy wizardry. Face it; most software has really been done before. For everybody working on a new AI system, there are a thousand making a text editor. For every professional kernel writer, there are a thousand people making accounting systems. The discipline of SoftwareEngineering is doing what has already been done, far from the bleeding edge, and doing it quickly and cheaply.
To contrast, consider the twin disciplines of chemistry and chemical engineering. Chemistry is a science; chemical engineering is an engineering discipline. If an oil company has a chemist and a chemical engineer, they use them quite differently.
The assignment for a chemist might be "Create a compound that can be added to gasoline to dissolve the cruft that accumulates in the valves". Once the chemist succeeds, the company will take the result to the chemical engineer (along with a half-liter sample of the stuff). The engineer's assignment will be along the lines of "Here is the compound our chemist invented. Figure out how to make it for under seventy cents a liter".
To paraphrase Rob (again :O), CS is similar to studying various types of wood to determine the spread of breaking strength under tension and compression; SE is analogous to the structural engineer determining and/or applying safe loads to a given design; somebody still has to build the house. Software has traditionally been the design, so house building was also design. -- gb
Hey Rob, a really great analogy. "An engineer can do for a dime what any fool can do for a dollar".
See also TheChemicalEngineeringCulture
However, more and more 'software' is connecting systems together to pass information between them (the WorldWideWeb comes to mind). One can argue that for most software applications anymore, neither CS nor SE is required to 'build the house' but the ability to apply basic rules of thumb (use a 2x4 stud every 16 inches; use 14 gauge Romex for typical lighting circuits, etc.) The application programmer doesn't need to know except in an abstract sense 'why' studs are that far apart, or why we're using XML. So ApplicationProgramming? is a 3rd discipline, which ranges from writing Excel scripts to building minor or even major web applications using pre-defined application-level languages (AllaireColdFusion, PHP, JSP) and pays little attention to classic engineering issues, most of the time. Sometimes we bring in a Structural/Software Engineer to determine if, e.g., a given pipe will carry the necessary data. -- gb
My arguments for why universities don't teach software engineering is simply that to teach it well you need practical experience, and to get that experience you need to practice, and you can earn two to five times as much in industry as against in universities.
So the people left to teach either can't get real jobs, or for some reason would rather teach (the big reason, of course, being to do research). Neither of these kinds of people are conducive to a good software engineering programme.
If you mean, an exact, rigorous calculation with tight error bounds that are guaranteed, and that implementation confirms, ok, that's rare.
But estimates that are indeed in the right ballpark, on the other hand, is pretty common in my experience, although not an everyday activity -- usually at the start of a big project or upgrade. Someone has to specify how many servers with what kind of disk and RAM to buy, for instance.
So I'm not sure I get what you're driving at. That CS tends to be much less exacting than e.g. chemical engineering? Yeah, no doubt. -- DougMerritt
Perhaps instead of these academic metaphors, we should think of it in terms of a master/apprentice model. We have software "masters" - and we can all learn much from them. This way accumulated practical wisdom is passed along from master to apprentice. We have "grandmasters" such as WardCunningham, KentBeck, MartinFowler, SamAdams, BillAtkinson, and we can learn a great deal from them. There is a craft aspect to programming which only experience can improve. A taught course can prepare students for entering a career in software engineering, but they must still 'bust their chops' to get any predictive intuition. The process is accelerated by 'wisdom osmosis' alongside master craftspeople. This approach is emphasized in Oriental schools where there is a rapid iteration of theory then practice practice practice, then more theory and so on. There is the same approach in classical studies and it is still applied to building apprenticeships. All we need to do is teach some new dogs old tricks. Musicians study under other musicians. GeorgeSzell? studied under ArturoToscannini?. Both were great musicians. Neither was a "music engineer" or "music scientist". Perhaps someday we will begin to understand the why of these empirically successful practices. We're probably not there yet, though.
See also: ApprenticeshipInEducation
EditText of this page
(last edited April 10, 2012)
or FindPage with title or text search