[ramzyo]

> I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer.

Completely agree here. I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major, whereas 'Mechanical Engineering', 'Electrical Engineering', 'Civil Engineering', 'Chemical Engineering', etc. are the degrees associated with those professional titles. To your point, I don't think it's a simple matter of nomenclature (i.e. that CS and Software Engineering are synonymous). Not a CS major myself, but amongst my friends who did their undergrad in the US I don't think they had any classes that covered requirements gathering, putting together schedules, etc. Any CS majors here have a class/classes that covered those topics?

[naasking]

> I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major

Because we don't yet understand software engineering. There has been insufficient empirical study of what yields maintainable/performant/what-have-you code, of what sorts of abstractions are "good" for maintenance/reuse/etc., at what's needed to reliably predict a program's resource requirements, and many software developers balk at design tools that restrict their style to detect certain errors as early as possible, like type systems.

Software development is not yet an engineering discipline for all of these reasons, and more.

[marssaxman]

We will never understand software engineering in that way, because we are in the business of automating ourselves out of work. As soon as we understand part of the process well enough that it could become an engineering discipline, we simply build some new tools and let the robots handle that part of the job, moving the humans along to wherever today's frontier of uncertainty happens to be. We will never be engineers in the traditional sense, because that would be a waste of human brainpower.

[Kadin]

That seems to imply that there is a surplus of automatable jobs or job functions in "traditional" engineering disciplines, which is ... not really consistent with my experience. Those fields have had nearly as much computer power applied to them as software development, but yet their projects tend to be much better-defined and have a much greater success rate (would you hire a PE firm that had 40% of its bridges fall down?).

Personally I think the high failure rate of software projects is mostly because people on both sides of the equation regard it as generally acceptable, and aren't willing to pay what it would cost to bring software development in line with a traditional engineering discipline, where failure is typically worth guarding against, even if it drives costs up significantly.

[naasking]

You overestimate AI. Incompleteness is everywhere in CS. Overcoming these limitations is not trivial at all.

Besides, software hasn't automated any other engineering discipline, and those are much more straightforward because they're more mature and the principles understood.

[marssaxman]

I'm not talking about AI. I am making the claim that software engineering will never be "mature" in the sense we ascribe to other engineering disciplines, precisely because we will never completely understand what we are doing; once we do understand the principles involved, we build some new libraries or languages or other tools which automate that part of the process, and we move on to thinking about other things we don't understand yet.

[tj-teej]

+1 to this - not to say the cliche "AI is the future" statement, but careers span decades and if the fundamental dynamics of writing software changes mid-career you'll be glad you have a strong background in CS fundamentals rather than having taken "Java", "OO Programming", and "Scripting 101" classes.

[sidlls]

A strong background in fundamentals is sufficient for a very small number of programming tasks. Do not mistake my top-level comment as an endorsement of the status quo focus on CS minutiae that reigns in this industry.

Your comment is tantamount to claiming an engineer ought to have a strong understanding of theoretical physics fundamentals in order to adapt his career over the span of decades. The reality is substantially different.

[SyneRyder]

CS Major in Australia from around 2001 here, and our final project was a group project involving requirements documents, meetings (including finding times that suited everyone to meet), creating development schedules & milestones & resource allocation in Microsoft Project, meeting with the 'client' (in this case, our professor) to clarify requirements we weren't sure about. Then hacking together the product in Visual Basic. It's the closest we came to building a commercial / end-user software, and the most memorable part of my degree.

[manyxcxi]

At my uni (Oregon State) we had MIS (Management Information Systems), which covered a wide range of these topics. I switched to this from CS my junior year because I felt it wasn't preparing me for the professional world, and I was right- to a degree.

My CS curriculum had some Software Engineering classes (I believe they were actually called Software Engineering I and II) where we did requirements gathering, estimation, etc- it felt like all of SEII was requirements gathering and documentation. Besides those though, it was very theoretical, and since I was already working in the field while going to school I realized that the theories would be helpful, but not nearly as helpful as being able to plan, document, and manage tasks in the context of a project.

If CS is producing developers, MIS is definitely producing technical analysts. It was extremely light on any development (there were a few classes where people had to write code and it was like every other student was being asked to build a rocket to go to Mars). But it did a great job of teaching how to identify problems and apply technology based solutions to them. Not just fixing things by making code, organizational level solutions.

Armed with MIS and a minor CS (and one class short of a math minor) I hit the ground running and was quickly leading projects, then dev teams. Six years in I was a Director and was also leading a skunkworks Innovation Lab where I got to keep my hands dirty.

The absolute fundamental difference is that I got the hard core tech depth from so much time in CS (and actually using the tech in practice) but I got the study I needed for it's useful application in a business environment. Selling to leadership, planning, source control processes, etc.

Most developers show up with the mindset of a craftsman toiling away in their shop, wanting only to emerge with their beautiful creation when it's ready. Pragmatism and being able to accept trade offs because of time/money/whatever will always make developers stand out.

[tnecniv]

> Not a CS major myself, but amongst my friends who did their undergrad in the US I don't think they had any classes that covered requirements gathering, putting together schedules, etc. Any CS majors here have a class/classes that covered those topics?

We did this as part of our open ended senior project.

[ramzyo]

Interesting, maybe a more informative question for me would be - if you did have a class/classes that covered those topics, did you feel that they prepared you sufficiently for a job as a software engineer? But now I'm starting to sound like an alumni survey... :)

[learc83]

My degree required a class like this. It was the most useless class I took.

The theory heavy classes (automata, algorithms etc...) covered material that changes very slowly.

But, as a previous poster said "we don't yet understand software engineering." Because of this software engineering best practices change with the wind. As a result, the software engineering class was a hopelessly outdated survey of how software was built in the early 90s when our professor last worked in industry.

[scarface74]

Software Engineering doesn't change that rapidly.

The idea of iterative software development - that we now call "agile" was first documented in 1957

The Mythical Man Month was published in 1975 and is just as relevant today as it was when it was written.

Code Complete came out in 1993 and is still relevant.

Even when you start talking about programming languages, both Java and C# have been popular in the enterprise since 2005.

[Fishkins]

I took a class titled "Software Engineering" (or maybe "Software Development") that covered these things. I believe it was one of several upper-level electives I could have chosen, though, so I could have avoided taking it and still gotten my CS degree.

[chrismcb]

Requirements gathering and scheduling and the ilk are but a part of computer science. They shouldn't be, it is a different discipline. This is what a systems analyst or a designer sighs be doing. Now maybe in a small company a programmer had to wear multiple hats, and it might be a good idea to learn some of that. But in specific it isn't a computer scientists job.

[Kadin]

That may be true, but if that is the case and you want to define a "computer scientist's" job that way, not many people are actually interested in hiring computer scientists.

What most firms are interested in are software engineers. The dearth of software engineers has led them to hire computer scientists (and, in fact, a rather large percentage of computer scientists that I know are quite happy for this).

But if you proceed down that road, I am not sure that what's left over, in terms of value-add, for the pure-play "computer scientist" who doesn't want to deal with requirements or schedule or that other messy stuff, really is. Once you have the problem suitably defined and the requirements nailed down... you can offshore the hell out of that job, or farm it out to some bidding-war site, and let people chisel each other out of a living wage while you laugh all the way to the bank.

I wouldn't want to hang my career on that. If you're willing to deal with the messy human-factors stuff, and sit in on the requirements-gathering meetings and deal with the client and work on setting the schedule and doing the estimation with the BD guys and all of that other shit ... you're never going to have to worry about some dude in India taking your job. That's not to say you don't need the technical skill. But if you're gunning for a job and it's between two people and one is a little better on the technical side but the other person can get involved in the process that much earlier, maybe iterate on the problem as part of requirements development (as many modern methodologies basically require)... I think they're going to do a lot better.

If you're a "throw it over the wall" coder, well, good luck with that. There are certainly jobs around for pure coders, but I tend to be suspicious of exactly how many (particularly if you want to make a top-end First World salary), and I suspect strongly that supply is going to outstrip demand for a generation or two.

FWIW, some of the most highly-compensated people I know are the ones who have some combination of really impressive technical skills but also have the business understanding and can participate in the process from kickoff, or close to it. It's also easier for them to negotiate since they have the option of going out on their own at pretty much any point, vs. a pure-play coder essentially depends on having someone around to feed them requirements and technical problems to solve.

The good thing is that I think a lot of people who think of themselves as pure coders probably have more business understanding (in some area) than they give themselves credit for, it's just a matter of developing that understanding, which can be hard in an organization that intentionally tries to keep its developers away from "the business".

[sidlls]

"Software Engineering" does exist as a degree. Or it used to (15 years ago).

[lomnakkus]

Indeed, it does exist, but IME SE education is just "CS light". I'm not saying that to be disparaging for the sake of it[4], but: there's nothing close to traditional engineering in the software development world[2]. It's basically just business interests coopting the term to try to seem more legit -- and of course they established the equivalent of trade schools for CS as SE. For those in the know SE education is a complete joke. (Disclaimer: Anecdotal, obviously, but I've been a university educator, in a position to hire, etc. etc.)

Just to avoid the inevitable pedantry: Obviously there are people who are serious about this type of thing[1], but in the mainstream and in practice "software engineering" is a complete joke.

[1] E.g. Greg Wilson. WATCH HIS TALKS. Seriously. He's amazing at exposing how absurdly irrational we are when it comes to education and development in general.

[2] I'm not sure why we would expect there to be. Programs, by Turing Completeness, are absurdly non-linear and unpredictable. I'm not sure engineering in such circumstances is even possible nevermind practical. See also [3] to have your mind blown. Engineering is ultimately based on physics which is "linear" in our everyday world (pedantry alert), but "computing" apparently doesn't quite submit to those parameters.

[3] https://en.wikipedia.org/wiki/Busy_beaver (specifically non-computability)

[4] Also, I'd like to add: CS doesn't even remotely prepare you for actually dealing with customers (which is probably the eventual fate of most CS students), but that just means that CS people might need supplemental courses in "requirements analysis"... but they should have had a bit of that when trying to game tests?!? I know that I did game "expectations" massively during my university experience.

[learc83]

Software is less like mechanical engineering and more like industrial engineering or systems engineering.

Designing an assembly line to build a car vs designing a car.

The difference even with those disciplines is that with code, any specification sufficiently detailed to replicate the product is the product.

An architect can design a blueprint for a house and send it to 3 different builders and they will each build more or less the exact same house.

But if you write a software spec and send it to 3 different software teams, you will get 3 very different products. If you try to write a sufficiently detailed spec to avoid this problem, you'll just end up writing code.

[lomnakkus]

This is not exactly a "response", but as you point out, I failed to point this out in my comment: There is little actual value in (what are you doing here? go outside).

Obviously, I'll elaborate if necessary, but really... do you actually need other people to tell you how to live? (Ding, another achievement realized. No, not really, I just thought it would be funny.)

EDIT: For a more comprehensive treatment see the film "Scott Pilgrim ..."