Science involves research and the testing of hypotheses. Okay, if a programmer is doing peer-reviewed, published research into a new field of computing which has not already been thoroughly documented, then they might call themselves computer scientists, but that accounts for almost nobody in the field. People doing cutting-edge research into areas like AI, UX, encryption, security, etc could just scrape a "science" badge, but only in as much as cutting-edge mathematicians might.
Programming is an ENGINEERING subject, and as programmers we should behave like proper engineers.
- logbooks and methodical records of our works.
- documentation of everything we've designed, how it works, what decisions we made, and why we chose that way.
- commenting our code.
- understanding failure modes.
- understanding that no code can be perfect, that we will unavoidably have errors in our code, and how to write rugged code that will survive this.
- designing modular code for maintainability and reusability, and worrying about performance tuning as the last step.
- knowing and understanding the algorithms involved and how they scale (O-notation) so that we *never* need to worry about performance tuning.
- knowing industry best practices (common patterns and antipatterns; documentation in comments with the code; pair programming and code reviews; cost/benefit analysis; IEEE and ISO standards for software engineering; iterative development; etc etc). Most CompSci graduates, when asked "What do you consider to be industry best practices" will give a deer-in-headlights look. MechEng graduates can cite chapter and verse from ISO standards.
- knowing how to estimate how long a project will take. NO graduates have this ability. I have seriously never met a CompSci trained in this, but it's considered a critical ability in MechEng. This is a systemic problem; in the US in the 90s, $81Bn was spent on cancelled projects, at least 30% of projects went unfinished, and more than 50% went over twice the intended budget. And it's not a heck of a lot better today.
- systematically designing our code, in writing, using some predetermined process, rather than just plunging in and writing it ad hoc. Requirements and specifications documentation.
- designing around unit testing, not just writing code then checking that it compiles and runs, and calling that testing.
- seeing a project to completion, not just working on the sexy bits that are new to us (scientist thinking) and then dropping the project unfinished because we got bored.
- not saying, whenever faced with a problem "this codebase needs rewriting in [current pet language]". That's not a solution. That's just adding a new problem. A MechEnger, faced with building a bridge, would never say "This road needs to be re-routed".
- working with the team and the codebase, and not being a hotshot.
- knowing industry standard tools (versioning systems, IDEs, bug tracking software).
Not all of these are possible in any project. For example, a manager might claim "you only get one chance to make a first impression" even while standing in a firehose, and force waterfall development rather than iterative. But that doesn't mean it should be the default behavior.
Mathematicians and scientists work alone make brittle, tangled, throwaway apps to prove some point. They make good demos, and good toy programs where the whole system can be understood by a single person, but *that's it*.
Engineers work in teams to craft clean, rugged, lasting, modular *systems* that can be maintained by other teams for decades.
Teachers: please train more software engineers. The computing world needs them. And if anyone uses the word "science" in the same sentence as "computer" when they are not wearing a lab coat, please do everyone a favor and slap them upside the head.
[This post was a response to Mosh's otherwise perfectly good post, where he made the mistake of using the S-word together with computing, and so fired up my rant machine]