Question : Is the science and art of CS dead? By that I mean, the real requirements to think, plan and efficiently solve problems seems to be falling away from CS these days. The field seems to be lowering the entry-barrier so more people can 'program' without having to learn how to truly program.

Background : I'm a recent graduate with a BS in Computer Science. I'm working a starting position at a decent sized company in the IT department. I mostly do .NET and other Microsoft technologies at my job, but before this I've done Java stuff through internships and the like. I personally am a C++ programmer for my own for-fun projects.

In Depth : Through the work I've been doing, it seems to me that the intense disciplines of a real science don't exist in CS anymore. In the past, programmers had to solve problems efficiently in order for systems to be robust and quick. But now, with the prevailing technologies like .NET, Java and scripting languages, it seems like efficiency and robustness have been traded for ease of development.

Most of the colleagues that I work with don't even have degrees in Computer Science. Most graduated with Electrical Engineering degrees, a few with Software Engineering, even some who came from tech schools without a 4 year program. Yet they get by just fine without having the technical background of CS, without having studied theories and algorithms, without having any regard for making an elegant solution (they just go for the easiest, cheapest solution).

The company pushes us to use Microsoft technologies, which take all the real thought out of the matter and replace it with libraries and tools that can auto-build your project for you half the time. I'm not trying to hate on the languages, I understand that they serve a purpose and do it well, but when your employees don't know how a hash-table works, and use the wrong sorting methods, or run SQL commands that are horribly inefficient (but get the job done in an acceptable time), it feels like more effort is being put into developing technologies that coddle new 'programmers' rather than actually teaching people how to do things right.

I am interested in making efficient and, in my opinion, beautiful programs. If there is a better way to do it, I'd rather go back and refactor it than let it slide. But in the corporate world, they push me to complete tasks quickly rather than elegantly. And that really bugs me.

Is this what I'm going to be looking forward to the rest of my life? Are there still positions out there for people who love the science and art of CS rather than just the paycheck?

And on the same note, here's a good read if you haven't seen it before The Perils Of Java Schools

  • 2
    Two things - 1. Development doesn't have to be hard. 2. Well-written programs will be essential in situations where scalability is important, which is where you will presumably shine through. I agree with what you're saying in principle though. Though I consider myself a novice programmer, I'm interested in learning everything at a low-level (to an extent) and not using pre-written frameworks, and so on... (at least to begin with... or when I do use any kind of framework it'll be my own. – Anonymous Jun 20 '11 at 15:23
  • 48
    I think your confusing CS with programming, these are related but two different things. – Darknight Jun 20 '11 at 15:36
  • 1
    @chris I totally agree. I make extensive use of frameworks and libraries, but I try to do them without first to understand the problem and how the library solves it. Once I know, then I can choose which library solves it best IN THIS INSTANCE, instead of just throwing a generic library at every problem and hoping it sticks – Veaviticus Jun 20 '11 at 15:42
  • 8
    What problem are you attempting to solve with this question? – Jeremy Jun 20 '11 at 15:44
  • 15
    @Veaviticus, really you expect your plumbers to know fluid dynamics (so that they can do their jobs better?). The majority of Line Of Business applications (desktop/web) do not require to solve highly complex problems (very rarely). Does having a background in CS help yes! most certainly. Is it required for LOB -> not really. – Darknight Jun 20 '11 at 16:05

13 Answers 13


Yes...and No

Good question, but bad assumption.

The Science part of the education does seem to be lacking, but the assumption that the science was there merely to make programs efficient is misguided.

The science was necessary to teach people how to define and solve problems.

Sadly, this part of some "CS" curriculums (curricula?) seems to be omitted completely, replaced by toy problems with trivial or known solutions, and intended merely to teach familiarity with tools

Disappointing; many Java school graduates were shortchanged, never taught how to decompose a problem, design an algorithm, specify a test or even debug effectively.

  • 3
    I attended a school that didn't even stress Java that much, most of what I did was in C++. But they still didn't teach us how to do any of the things you mention. They covered the basics, skimmed some stuff and went in depth on what each professor was interested in. It seems like schools these days are trying to pump out as many 'developers' instead of scientists as possible. – Veaviticus Jun 20 '11 at 15:40
  • @Veaviticus: That would be for the fortunate students. At my university, the professors have a schizophrenic level of abstraction and their idea of an examination is "recite formal definition". – DeadMG Apr 4 '12 at 18:31
  • The language has nothing to do with the teachings of decomposing a problem. A problem is a problem regardless of whether it is C, Java, or Ruby. – Rig Apr 4 '12 at 19:01

Is the science of Computer Science dead?" ... "I'm a recent graduate with a BS in Computer Science. I'm working a starting position at a decent sized company in the IT department.

Quite honestly, my own two cents: You will not find the "science" of computer science working in an IT department at a decent-sized company, because it's the IT department, not CS department. Try going back to school for a PhD, or working in the engineering departments of a company whose focus is computer science (e.g., image-processing, high-performance networks, computer algebra systems, aerospace, etc...). This is where you'll find the hard, interesting problems where sloppy design [generally] won't be tolerated.

"Are there still positions out there for people who love the science and art of CS rather than just the paycheck?"

Yes, absolutely, but probably not at IT departments of mid-size companies.


If you are a programmer, do not consider yourself a "computer scientist"; computer scientists are the ones creating the next generation of computers, some of which are still science fiction until the correct mix of materials, miniatuization and computational theory are derived. They are only the start of the pipeline. People who develop software in the here and now are "software engineers"; they take the theories and tools, sometimes layering practical theory and real-world tools on top, to harness the power in potentia of this complex piece of electroinic wizardry and make it do what we want. That is in turn one specialization of the field of "computer engineering", which takes the theories of the computer scientists and applies them, hardware and software, to real-world end-user electronic solutions.

This is, IMO, where business meets theory. In these types of cases, the old adage "the enemy of better is good enough" can easily be turned around to read "the enemy of good enough is better". Considering yourself an "engineer" instead of a "scientist", and putting what you do in parallel with other engineering disciplines, throws the differences into relief.

Let's say a client comes to you, a civil/structural engineer, and asks you to build a bridge. The bridge needs to span 20 feet, support itself and one ton carry load, it should last 10 years with routine maintenance, and they want it in a month for $20,000. Those are your constraints; meet the minimums while not exceeding maximums. Doing that is "good enough", and gets you the paycheck. It would be poor engineering for you to build the Golden Gate Bridge, far exceeding both the design specs and the budget by several orders of magnitude. You usually end up eating the cost overruns and paying penalties for time overages. It would also be poor engineering for you to construct a rope bridge rated for the weight of 5 grown men even though it cost only $1000 in time and materials; you don't get good client reviews and testimonials, and depending on your contract you'll be told to take it down and do it again, for no additional money beyond the contract.

Back into software, say you have a client who needs a file-processing system built to digest files coming in and put the information into the system. They want it done in a week and it has to handle five files a day, about 10MB worth of data, 'cause that's all the traffic they currently get. Your precious theories largely go out the window; your task is to build a product that meets those specs in a week, because by doing so you also meet the client's cost budget (as materials are generally a drop in the bucket for a software contract of this size). Spending two weeks, even for ten times the gain, is not an option, but most likely, neither is a program built in a day that can only handle half the throughput, with instruction to have two copies running.

If you think this is a fringe case, you are wrong; this is the daily environment of most in-housers. The reason is ROI; this initial program doesn't cost much and will thus pay for itself very quickly. WHEN the end users need it to do more or go faster, the code can be refactored and scaled.

That's the main reason behind the current state of programming; the assumption, borne out by the entire history of computing, is that a program is NEVER static. It will always need to be upgraded and it will eventually be replaced. In parallel, the constant improvement of computers on which the programs run both allow for decreased attention to theoretical efficiency, and increased attention to scalability and parallelization (an algorithm that runs in N-squared time but that can be parallelized to run on N cores will appear linear, and often the cost of more hardware is cheaper than that of developers to devise a more efficient solution).

On top of that, there is the very simple tenet that every line of developer code is something else that can go wrong. The less a developer writes, the less likely it is that what he writes has a problem. This isn't a criticism of anyone's "bug rate"; it's a simple statement of fact. You may know how to write a MergeSort backwards and forwards in 5 languages, but if you fat-finger just one identifier in one line of code the entire Sort doesn't work, and if the compiler didn't catch it it could take you hours to debug it. Contrast that with List.Sort(); it's there, it's efficient in the general case, and, here's the best thing, it already works.

So, a lot of the features of modern platforms, and tenets of modern design methodologies, were built with this in mind:

  • OOP - build related data and logic into an object, and wherever the concept of that object is valid, so it the object, or a more specialized derivation.
  • Pre-built templates - a good 60% or more of code is syntactical cruft and the basics of getting the program to show something on-screen. By standardizing and auto-generating this code, you reduce the developer's workload by half, allowing an increase in productivity.
  • Libraries of algorithms and data structures - As in the above, you may know how to write a Stack, Queue, QuickSort, etc, but why do you have to, when there's a library of code that has all this built in? You wouldn't rewrite IIS or Apache because you needed a website, so why implement a QuickSort algorithm or a red-black tree object when several great implementations are available?
  • Fluent interfaces - Along the same lines, you may have an algorithm that filters and sorts records. It's fast, but it's probably not very readable; it would take your junior developer a day just to understand it, let alone make the surgical change needed to sort on an additional field in the record object. Instead, libraries like Linq replace a lot of very ugly, often brittle code with one or two lines of configurable method calls to turn a list of objects into filtered, sorted, projected objects.
  • 2
    Good answer, but you miss one important point. "That which I cannot duplicate, I do not understand." Knowing how they work doesn't imply that you hand type them for every project; rather, it ensures that you know each of their strengths and weaknesses which will help you pick the best one. Then, all you have to know is whether that algorithm/data structure is in your standard library. – Michael K Jun 20 '11 at 18:24
  • Except that your adage is wrong; I can understand very clearly the concepts behind some material thing that I have no hope of successfully duplicating. I agree in principle; a successful engineer of any kind needs to know enough theory to pick the solution that works. That doesn't mean that an engineer has to be able to build every type of light bulb in order to know each one's specs and thus choose the right one for a house. Similarly, I can use a red-black tree, understanding its performance and proper application, without having a clue how to implement one from scratch. – KeithS Jun 20 '11 at 18:35
  • The analogy with engineering is not a good one. It's not the case that a "better bridge" in CS necessarily costs a lot - it's often just a question of understanding which tool is appropriate for the right job. Even implementing a pretty complex text-book algorithm is often way out of people's comfort zone, yet it's not a difficult or expensive notion (depending on scope - but assuming this is a project in man-years, not man-days). Usually it's even easier - no custom implementation, just a question of knowing the right tool and the keywords to google for. – Eamon Nerbonne Jun 1 '14 at 19:43

IT seems to me that you are doing IT and not CS and that shouldn't imply that CS is dead. CS is not dead, is just that most jobs are in Software development. Since most CS students learn to program, they usually end-up hire as programmers and not as a computer scientist. Computer Science jobs are miniscule comparing to programming jobs. You might even doing a complex app using computer science techniques, but in my opinion (and I don't like opinion-answers because they are subjective), that falls in engineering camp than a scientist camp.

Also, beautiful and elegant code is in the eye of the beholder, but for most companies/managers, having a good-enough-design on time is far more important than beautiful code but never finishing on time.

Lastly, there is the real world and lala-land. Unfortunately, we get the paycheck from the former, and that is where the "science/art" of software development comes in on how to produce high software quality with time/budget constraints. I felt the same type of feelings that you have at the beginning of my career. I always wanted to create "the-best", but soon I realize that "the-best" is not the most efficient or elegant, but the most cost-efficient design.

  • 3
    "beautiful and elegant code" vs "good enuogh, but on time" is a false dichotomy. It's easier to finish on time if your design is simple, and simple design equals beautiful design. Only, simple doesn't mean simplistic. – pillmuncher Jun 20 '11 at 17:08
  • 1
    @pillmuncher, Yes I agree, to me, a beautiful code is simple (but not simpler) but unfortunately that premise is a subjective/relative. "simple design equals beautiful design" is not an assertion but an opinion (a very popular opinion that I agree 100%, but still an opinion). What is not an opinion, is schedule, requirements and cost. Those constraints will tend to lead to a good-enough-design for the given constrains. – Armando Jun 20 '11 at 17:30
  • "[1]IT seems to me that you are doing IT and not CS and that shouldn't imply that CS is dead. [2] CS is not dead, is just that most jobs are in Software development". Your 1st statement is correct -- the OP is in IT and not CS. I do take issue with your second statement, however, as many so-called "computer scientists" also do software dev. It's called "research and development", and an example may be of computer scientists defining, solving, and proving the correctness of a routing algorithm over certain networking topologies, then implementing the "official" or prototype implementation – Bill VB Jun 20 '11 at 21:08

First of all, you got it wrong. "think, plan and efficiently solve problems" is not science, it's engineering. Science is lot more about exploring new fields. And actually in academic world people care much less about efficiency of the code much less, than in industry. In academia it's more about proof-of-concepts etc.

No, what you're describing, is that less in-depth knowledge is required for software development. Which might be true, if the requirements would be the same. But nowadays, software engineer is expected to know how to deal with multi-threading, distributed computing, scaling etc. They are expected to know how to lead project efficiently. Most of this wasn't at all in curricula few decades ago.

  • It still isn't, from what I'm reading here. Many schools don't teach engineering, they teach languages. That's tantamount to merely teaching Autocad to a civil engineering student. – Michael K Jun 20 '11 at 18:19
  • @Michael: Haven't seen any decent university do that. – vartec Jun 20 '11 at 22:17
  • 1
    I go to RIT. It's ranked highly, and still rather crappy. No school teaches programming right, because it simply cannot be done in only four or five years in the context of other coursework. – Jon Purdy Jun 21 '11 at 6:35

I don't think what you've said is exactly right, but you do have something of a point anyway. Specifically, I think over time, computer science and software engineering have grown apart.

Software engineering (like other engineering) is about applying science to build products, solve problems, etc. Computer science is primarily about research into algorithms and (though this part is often somewhat forgotten) how to implement those algorithms (at least in some theoretical sense -- e.g., perhaps treating all PRAM machines as equivalent).

Keeping those in mind, I think the reason behind the bifurcation becomes apparent: most of the algorithmic problems involved in something like a typical web site have been solved already -- most of them, a long time ago. Perhaps more importantly, most of those have been solved well enough that for the average web developer, the problem has disappeared almost completely. For example, doing atomic updates to distributed databases is definitely a non-trivial task -- but a typical web developer just writes some SQL, and has no clue (or care) about how much research it took to figure out how to make the work dependably.

At one time, it was essentially impossible to separate computer science from software engineering. So few problems had been solved that writing even a relatively trivial program required research into the fundamentals. If you wanted to do something as simple as sorting a bunch of data in the late '50s or early '60s, chances were pretty good that you were going to just about going to have to do some analysis of your data, and try to design an algorithm that fit as well as possible with what it would take to sort that particular data -- nowhere close to as many sorting algorithms were known as today, and even the algorithms that were known weren't known nearly as well as they are today.

50 years of research and development have paid off though -- most typical development can use not only known algorithms, but pre-written implementations. Most typical problems can be solved quite reasonably based on existing knowledge (and even existing implementations) of algorithms.

That doesn't mean computer science is dead though -- there are still more algorithms to research, and people doing research into them. It does mean, however, that most of the research is more specialized, and only likely to apply to fairly specialized areas. There's probably also a greater "gap" between acquiring and applying the knowledge. At one time, you figured out a better way of sorting in the process of writing a sorting program, and it was written into real code almost immediately. Now a lot of computer science is devoted to things like how to use an essentially infinite number of processors -- which will probably be useful someday, but even primitive tribes wouldn't count the dual cores in my computer as "many"... :-)


Software development and computer science are not the same thing, and I found that most of my classmates in a B.Sc. Comp Sci program were frustrated by this.

I think of software as a product of computer science ... like paintings are a product of visual art.

I think that most people with CS degrees get hired into jobs to perform software development, especially in the early stages of their careers. I think that a lot of people in this role stay there and don't go any further.

I think the difference starts to appear when new problems or paradigms appear or when "slapping it together" isn't good enough. Who builds the new frameworks or languages? Who sits down and hammers out the details of a new physics engine? Who uses graph theory/graph transformations to squeek out a few cycles per iteration of performance from an algorithm?

I'll finish where I started, agreeing that there are a lot of computer scientists in software development/engineering roles, perhaps not living up to their potential.


You seem to be confusing computer science with programming and software development in general. The two are not the same, not even close. Regardless of what our degrees may say, the vast majority of us are programmers, not computer scientists. Unless you are actively involved in academia at a high level then I would wager that you don't really have any idea as to what is going on in computer science.


I can tell you that Computer Science is alive and well. I am have to new solve problems daily and come up with an effective and elegant solution to those problems. I have to use my skills as an engineer daily and use the knowlege of myself and my colleagues to solve those problems for our customer.

I'm not trying to hate on the languages, I understand that they serve a purpose and do it well, but when your employees don't know how a hash-table works, and use the wrong sorting methods, or run SQL commands that are horribly inefficient (but get the job done in an acceptable time), it feels like more effort is being put into developing technologies that coddle new 'programmers' rather than actually teaching people how to do things right.

This sounds like a problem with the employee and certainly not true for every programmer.

Just because tools that make our job easier do exists does not mean we shouldn't understand the underline technology, if we don't we are not helping anyone and certainly are not doing our jobs in solving problems the correct way.

  • I agree. I'm not trying to say there are no jobs that don't need thinking, or that all developers have no idea what they're doing, but having just come from a CS program, I can tell you that my school didn't teach me half the things I know now. I learned them on my own. And now that I know them, I can use frameworks that do it for me. But if I hadn't learned it on my own, I would be just blindly using a framework, most often incorrectly – Veaviticus Jun 20 '11 at 15:37

You just haven't understood the problem at hand. The problem isn't getting the maximum performance- it's getting enough performance for your app to be responsive and fast enough. Learning to program is about solving the problem, for the smallest amount of money.

I hate to phrase it this way, but any impression you are under about the death of CS is just your own pre-conceptions of what a "real" programmer should have to do.

  • Right. I know businesses need to make money. And I am certainly not innocent of making parts of my applications 'fast enough' instead of the best they can be. I'm more curious about the trend as a whole that many (at least from what I can tell) developers haven't ever studied CS. They came into the field from elsewhere, and have little to no real theory behind them, just experience with frameworks – Veaviticus Jun 20 '11 at 15:56
  • @Veaviticus: Using a framework may not be ground-breaking academic theory, but it's definitely still CS. – DeadMG Jun 20 '11 at 16:46

Well, dead or not is debatable!

The fact is that in today's technological era most companies hire people to solve real world workflow type tasks through software automation. They are not interested in how elegant or faster a program you can write, as long as it allows the business to execute faster with higher output.

The stress is on more output in less time. (Think commercialization of crops/food; faster and more growth with less cost). The same is happening in tech world (the next new idea).

Remember, in this day and age, things are moving faster than ever before due to the amount and access to knowledge than back in the days. In those old days, output was small and better, profits were greater. Now, the game has changed completely. Just look at the things like quality of customer service and in general things don't last longer.

Elegance and efficiency matters to tech companies like Google etc., while even those places are not perfect but you can come close to it by working one of those companies in the coming years.

There's always a trade-off in life. You can find a job that pays less, where you have all the time and attention. Or, you choose to swim with the rest of us for better pay and ignore stuff that is not perfect. The faster this realization sinks in you, you can gear yourself for the real world. I am not saying you should ignore quality and elegance but know the dynamics. You'll be Happier :)


To my mind some of the most interesting things the future might hold will certainly be based on the science part of the computer science, specifically improved computer vision / machine learning and other sematisizing algorithms. These will probably be pushed forward in industry (e.g. take the Microsoft Kinect) but are such hugely difficult problems they will certainly be based on the large body of research and progress made in academics (again, take the Microsoft Kinect).


I think standard day to day programming is about as much of an art as a science but there certainly exists areas that are deeply interested in the science aspects of computer science. For example researchers for companies and universities. If you truly want to be involved in the sciences professionally then you should seek a phd. However, I have found the science parts of my education to be continually valuable, despite also needing to rely on my more creative side in reality!

People who don't know what they're doing can hack things out with some of the tools you mentioned but they usually hire the real CS people to make the tools, you've just got to get more abstract to really push yourself.

Not the answer you're looking for? Browse other questions tagged or ask your own question.