Software Engineering Vs Computer Science

On one hand you have ComputerScience, and on the other hand you have SoftwareEngineering, which for the purpose of this pattern will be used to refer only to the set of generally accepted practices, methodologies, and standards that drive the SoftwareDevelopment industry.

There is an increasingly strong tendency of SoftwareEngineering to go away from and against ComputerScience. It is common sense nowadays that Software Engineering cannot be based on ComputerScience alone, and in the later years, SoftwareEngineering integrated new approaches and perspectives rooted in Economy, Psychology and Sociology, and Cognitive Science to name but a few border domains. However this integration seems to have marginalized ComputerScience as the only true foundation for SoftwareEngineering.

However this integration seems to have marginalized ComputerScience as the only true foundation for SoftwareEngineering.

The only true foundation? It seems to me that there are two equally necessary foundations for any engineering discipline:

the theoretical underpinning (ComputerScience in the case of SoftwareEngineering, or electrophysics in the case of electrical engineering, etc.),
and what I will call for the moment the "practices of engineering", that aspect of engineering that can be factored out of any engineering discipline -- understanding the customer's problem, determining requirements, how to approach design, etc.

Without the theoretical basis, you have a person who knows how to be an engineer, but can't do any particular kind of engineering. But without the engineering-practices knowledge, you have a technically knowledgeable person whose ideas cannot be well applied to an actual engineering problem. --MikeSmith

You're right, ThankYou, the only true foundation is a little bit strong, maybe it needs to be replaced with a sine qua non foundation. The engineering practices you mention here like requirements engineering, tend to have a serious theoretical framework underneath them (unfortunately largely ignored in practice).

I don't see what makes this an AntiPattern. It's not a pattern in the first place, it's more of a point of view. I see the continued separation and compartmentalization of CS and SE as natural and desirable, in much the same way that science has formed physics, chemistry, biology, various sub-disciplines of engineering, and even math and logic. The fact that we (here in Wiki) tend to focus mostly on SE at the expense of CS is that this is where we make our money and devote our time. Universities tend to do the reverse. I learned very little about the business of programming at university. I seriously doubt if further study of CS would improve my day-to-day activities of programming. Instead I focus on SE, where the benefits are greater.

There's a lot of work to demonstrate that this is indeed a pattern, that's why I postponed a full argumentation, not to mention there's a lot of throny issues involved. However, it is not only my feeling and my best jdugement of the situation, I have lots of friends in the industry and some in the academic who make the same judgement. But we can try to analyze some examples of evolutions in the practice of software development, and see how they do from a CS point of view. I think there is a clear pattern in there.

The next big question to be resolved is how to get it back to what it should be, and until we'll get that done I predict there will be absolutely no significant improvement in the quality of SoftwareDevelopment, no matter how many marginal methods, theories, technologies standards we struggle to put in place (see ProcessImprovementTools, SoftwareEngineeringBodyOfKnowledge). -- CostinCozianu

Let's try to take a look at a few examples of technologies and practices that dominate the software development industry. It should be easy to see where they go.

UML. Although a multi-billion dollar industry in itself, UML doesn't support any significant concept from the wealth of theoretical OO related research, and the main concepts that it uses are at best undefined. The end result is that although UML arguably can't be worse than pen and paper, its lack of discipline, lack of semantics and the pop culture it draws around (including published books) make it easy for software engineers (in this case dressed up as "architects", "object architects", "object designers", "object modelers") to do sloppy work.
Programming languages. No language war here, but both Java and the upcoming C# could have used a bit more theory in their design, so we could have used less cast operators when programming, and could have benefitted from greater scale reuse and generic programming -- to say only the obvious about both of them. "I get secret satisfaction when bad ideas take hold and suck a lot of people in it ... like Java. (just teasing)" [DonaldKnuth].
Relational databases. Well, it is well known that relational databases aren't relational if we accept the relational model as it was defined by Dr. Codd and later developped in computer science. While the scientific community moved on beyond the relational model, the database industry is still catching its breath trying to implement even something that resembles it. The future evolution is not at all encouraging, some of them have introduced objects and pointers back into their relational model, and in that package they put very nice sounding operators like IS_DANGLING(<reference>) and tons of other niceties like native XML. The consequences of the departure from the scientific foundation are unfortunately of very practical nature.
J2EE. The great innovation and the centerpiece of the mumbo jumbo, entity beans are not even able to model what they are supposed to model, at least at the level of E-R in 1976, not to mention other great deficiencies, that will deem them unsuitable at any serious analysis. Who hasn't heard yet of serious project failures, performance problems, related to one of the biggest hype bubbles of today?

And the examples could go on and on with only very few exceptions ... I'd be curious to see if there's any significant technological area that we use in software development, which has made significant improvements along its bases in CS, and not against it or in ignorance of. -- CostinCozianu

Early computer technology was based closely on ideas from science and math. Later on as it matured, it became more like engineering. But as complexity has increased and hardware become less of an issue, it is moving more and more into areas of psychology. There are too many variables to measure using traditional engineering and scientific principles. The problem is that psychology is a messy, opinion-dominated discipline. As software needs progress more, it may even get into even fuzzier areas. AI, for example, does not have to depend on the human mind. The "?" may be politics.

: Science/math ---> Engineering ---> Psychology ---> ?

? = Voodoo. The above is a mistified account of what's happening. It's kind of a self-delusion.

Ontology? -- OntologyLanguage

It is true to say that only a considerable part of the unwashed masses moved towards psychology. Computing scienctist, a large area of engineers (especially in mission critical, performance critical and other areas). For example, Microsoft recenty hired TonyHoare with the specific mission to help in raising the quality of its software, and he is one of the main exponents of ProgrammingIsMath. If Microsoft believed in voodoo instead of math, they probably would have hired somebody else.

The voodoos are typically pursued by people who don't have a inclination for math, don't have the proper educational background, etc. Math and science in software engineering is perceived by those people as threatening to their position, and instead of raising their level of education, they are militantly pushing towards the voodoo area. It really doesn't matter, progress in ComputingScience is not defined by voodoo, so voodoo is unlikely to stick. It's yet another fad to be gone sooner or later.

A discussion on closely related subjects is ComputerScienceOrSoftwareEngineering.

See: ComputerScience, SoftwareEngineering, DisciplineEnvy, IsComputerScience, WhatIsScience, AbstractVsConcreteSoftware, DisciplineEnvy, ProgrammingIsMath