What is the best way to think of software development? Is it science? Is it art? Is it craft? Is it something else entirely? Read Steve McConnell’s article here.
Software Engineering, Not Computer Science
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
the link shown above takes you to the article:
http://tekmonkey.org/articles.php?page=Software_Engineering,_Not_Co…
Just linking back to self..
I think it depends on the project and how the programmer sees it.
If the project is exciting and the programmer really likes what he’s doing and has enough room to be creative, then I think it is something close to art.
It’s a craft. You do not step back and get a great masterpiece from bits of crap thrown on the wall, it is built layer upon layer by the tiniest brush stroke of the masters hand. Any project can be either david or a cow pie.
I think it also depends somewhat on the “development environment” in which the software is written, which might include such factors as:
* The specific languages and execution environments being used, which can heavily influence what can or cannot be done.
* The type of organizational structure and culture under which one operates (is a heavily structured or compartmentalized process in place with many people assuming limited/specialized roles, or are there a few Jack-of-all-trades programmers working in an old-school “agile” environment),
* The nature of the software being developed (in-house software which might be fairly malleable over time versus for-sale software that only exists as discrete static release levels),
Etc.
When I’m working on a utility of my own design, I’d say it’s as much art as engineering.
When I’m working on a formal application for external customer use and following a tight testing/QA process, it’s less art and more engineering.
When I whip together a quickie script for a one-time event, it’s sometimes closer to dart throwing. 🙂
high error rates in programming are due to the relativly cheapness of these errors. The fact that not software company will take responibility for the effects of the software they create also increase the number of errors because less effort is put in to finding errors because economically it’s not worth the effort.
Anything else that is engineered and sold, the engineer is responiable for the effects of the created product.
Browser: Links (2.1pre15; Linux 2.6.11-gentoo-r3 i686; fb)
> high error rates in programming are due to the relativly cheapness of these errors.
In essense, you’re saying that programming half way between a craft and engineering. Basically like architecture. As a side note, anyone taking project management classes will notice that two types of people tend to dominate those clases: software developers and high end contractors. It’s no coincidence. It’s amazing how many similarities software design and construction has with building design and construction. The key differences, as far as I can see, is that in contracting, when (not if) user’s come up with requests that require radical redesigns at the end of the project, you can simply point to the cost of the redesign and people tend to back down. The same sorts of quality versus features tradeoffs are still made and the same sorts of overrunns and external dependencies exist.
high error rates in programming are due to the relatively cheapness of these errors.
Exactly, when every fix is only a recompile away you ends up having a slightly different perspective than those who have material and production cost associated with their designs. Like mechanical or electronics engineers. But it’s common for both CS and SW engineers, and not really related to the science or engineering training.
“Art” is a very flexible word. Coming from my very small understanding of design I see computer programs in much the same way I approach a magazine, a restaurant’s menu or some product design: it’s applied art. In many ways design (of almost any kind, graphic, industrial etc.) is much like programming. There’s a lot of ground rules and guidelines, but there’s still zillions of ways to accomplish a single goal, this is where the science of rules and laws meets art and to a degree, personal preference.
There’s many ways one can go about doing something, and quite a few of them are really just fine to do, we can bicker all day about how a graphic design (or better yet an industrial design) or a paradigim in a piece of software is flawed but many times in the end, as long as whoever’s going to be using that design, reading it, or using that software “gets it” it’s ok.
Quite true, in art as in software the end user perception and experience are everything.
The age old Software Engineering versus Com Sci fight. Memories from university
Being a computer Engineer, I’m on the engineering side
Computer Science people can’t code…Just kidding.
I just find engineers better at judging when to optimize, how to handle errors, and using common and simple design patterns.
Maybe thats also due to their just being more computer science students that computer/software engineers so they’re of less quality
Don’t get me wrong, I’m sure they’re better at writing some sort algoritm. For me, its look it up and copy it
Ah. You are a Computer Engineer Yamin? I would like to talk to you! I would really like some information on computer engineering and what you did in college. You can contact me on icq/aim at 6337756 or email me at brandon @ kinmantech dot org. thanks!
Computer scientists are also trained how to properly use “their” vs. “there” and “that” vs. “than” :-).
“Maybe thats also due to their just being more computer science students that computer/software engineers so they’re of less quality
”
Should be:
“Maybe that’s also due to there just being more computer science students than computer/software engineers so they’re of less
Calm down, it’s the comment section of an internet meta-news site…
He’s not writing his thesis. Besides, he could be tired or something. Or he could just be completely ignorant of how to write in english.
The whole debate is very much like the question of whether architecture is an art or a science.
The most logical solution is to say that it’s both – you can be strict, methodical, scientific, and practical – and, you can be creative, inventive, unique, and passionate. When you migrate your philosophy to one extreme or the other, you create a recipe for failure. A purely artistic building might end up like the Gehry Springfield Opera House from the Simpsons – attractive from the outside, but utterly useless for most everyday tasks. On the flip side, a strictly-engineered building can be good for its designated purpose, but it will appear butt-ugly and cumbersome to the observer.
The solution is to balance both ends of the spectrum. Be creative in your problem solving, but know when to draw from proven methods when applicable. Be strict in your design practices, but be willing to put some more effort into one aspect or another if ‘The Passion’ seizes you.
In this way, you can come up with solutions that are both elegant and effective.
I think that another part of the problem is the vast range of variation in the talents, skills and egos of today’s programmers. Programmers who are not very talented might not realize that what they’re doing is a commonly-used design pattern, and more talented/ego-driven programmers might know it but choose to disregard preexisting solutions because “their way is better”. This is actually where so-called ‘extreme programming’ [specifically, pair programming] finds a practical application; it can be very useful for finding a middleground between the ego-driven programmers and the not incredibly talented programmers.
If you balance your programmer’s talents & egos, and find a middleground in the strictness of ‘engineering’ versus the freedom of the theoretical, you will no doubt notice an increase in the quality of the delivered products or services.
In programming as in life, extremes are an unnatural byproduct of refusal to believe that an equilibrium can be found.
Edited 2006-01-14 06:46
My understanding has always been that architecture is educated art. Structural Engineering is the science part.
But, I don’t make buildings, so maybe I have it totally wrong
.
why did philosophy have to exist? it’s science, learning the science behind the technology and using that same science to develop programs.
“The physicist might un- derstand the electrical principles better than the engineers he is working with. But his experience in building equipment is in creating prototypes that are used to advance the state of knowledge in a laboratory. He does not have experience or training in designing rugged, economical equipment that pro- vides practical solutions in real-world settings.”
That statement is what largely negates his entire premise that software design requires an engineering background which is centered in what works (because it has worked) and not what works (because it was in the latest journal).
Why?
All software is used to advance the state of knowledge… Seriously. We’re not making devices for factory production. We’re not writing blueprints for a person to follow. We’re not consuming materials.
We’re building abstract, complex, systems based on the latest technology (be that software platform, and hardware platform).
And education in modern software engineering techniques is not going to enable you to continue your whole life with them. An education in learning modern software engineering techniques is what you need.
You’re not going to suddenly make software a thousand times better simply by taking all that is good out of it: The creative side of it. What will happen is this:
1.) All the smart people will leave. Yes, they’ll be gone.
2.) A large number of mediocre people who are good at undergrad classes will fill those ranks.
3.) Software will be reliable, and advance at the pace of the internal combustion engine.
Besides, all the research on proving software is done in CS work. Not Software Engineering. At least at my University the “Software Engineering” classes are geared towards you completing projects. Where the CS theory classes are the only ones which even mention proving algorithms.
Of course, you can’t prove a complex program. At least, not if you want to ship it before the platform you wrote it for dissappears.
Anyway, the author goes on to take a more moderate view by giving the definition for engineering and saying that it can keep up:
“Engineering is the application of scientific principles toward practical ends.”
How is that not programming. How can you possibly program without applying scientific principles towards practical ends? By writing a program that isn’t meant to do something practical?
You certainly cannot write a program without some sort of scientific or mathematic principles… And you won’t figure out that it works in a mathematical way, I guarantee you’ll use a scientific approach for that!
I’m not against considering programmers “software engineers.” But this idea that the education cannot be achieved in a science college is a bit silly. I imagine most CS colleges have adapted to the fact that CS is different from the other sciences. The fact that most of the graduates work on more practical things.
As in other disciplines, scientists and engineers are both necessary and useful. The one you want for a given task depends on, well, what you need for that task. In many cases, the problem is well specified enough that the implementation itself is the major task, in which case a software engineer is necessary. In other cases, there isa problem that needs to be solved, and in such cases, its necessary to bring in a computer scientist, who can throw graph theory and combinatorics at it until he gets a nice description of a solution or algorithm. Doing the right thing at the right time saves either a lot of crappy code, or a lot of crappy algorithms.
I would call it a science. Much like science, in software there are methods and formulas, but, that doesn’t mean there are not the occasional ‘explosions’. When those happen – it feels a bit more like Alchamy
I’ve been thinking about this quite a bit lately. If I were to place a label on software development I would call it a trade. What we do on a daily basis is more like plumbing, or carpentry than engineering or science.
Science is concerned with advancing the state of the art, but most software development doesn’t do that. In fact it is rare that we get a chance to try and solve a truly new problem (unfortunatly).
Engineering is a discipline that allows its practitioners to create items with quantifiable results. For example the electrical and mechanical engineers I’ve worked with in the past were able to calculate within predetermined tolerance levels the behavior of the items they designed.
We seem to be lacking the quantification part in software engineering. The best we can do is estimate risk to quality and cost. This is usually no better than a developer’s best guess.
We are, as McConnell says, caught in a strange middle ground. We are trained in Science programs, but paid to do engineering. So in the end we often design and produce software that is far from ground breaking (how much can you advance the state of the art while customizing a CRM application?) in a skilled but non-exact manner. I would say that this is closer to a trade than anything else.
How many of programmers actually use those design methods, UML (suxxxxx (x->inf)) ? I’ve tried couple of them, but they don’t work for me.
Flow chart, author unknown, penciled on a bar napkin.
I much prefer doing pseudocode. Takes up less space, and if I use a text editor I can sometimes use the initial pseudocoded design as high-level program comments. 🙂
Programming Perl is sometimes an artform in the classic sense, as you can be as creative as you wish in solving the problem and no-one who doesn’t understand Perl (= art) will understand your work.
But seriously, it was an interesting article. I think there are too many mediocre and not enough highly skilled software engineers in the world. I mean, if the same ratio applied to architects, I’d be afraid to live in a three-storey house, let alone a skyscraper. I’m not sure if this applies only to where I live, but around half of the people studying computer science don’t actually understand fully what they’re doing when they program. They don’t have any practical knowledge about programming, only what they learn in the theory classes. It’s a bit scary to think what they’ll do when they get a job.
Or maybe that’s the very definition of an artist. Do they always know what they’re doing when they’re creating art? I don’t know almost any artists, so I’m in a kind of a void when it comes to this.
“If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.”
-Gerald Weinberg
Its Applied Scientific Art. As a mechanical engineer who then studied computer science I am in full agreement with Bill Joy who longs for the day that Software pseudo-Engineering becomes an discipline akin to how Mechanical Engineering, Electrical Engineering, Chemical Engineering, so on and so forth are engineering disciplines.
It sure as hell would make for a much greater understanding and reduction in confusion in programming practices which arise with differing professionals and their choice in design patterns, paradigms, so on and so forth.
With that said, my added background in the Computer Sciences only strengthens my recommitment to Mechanical Engineering and being able to apply more of its principles through the aide of computer systems and solutions, present and yet to be developed.
You could start with developing a pseudo compiler.
Is it art? Is it science? Is it… maybe what my former boss used to say, “like making french fries”?
That’s a good one. He used to say that in the end all software’s just the same, “some buttons and some graphics and press here and it does something. We’ve done that a million times”.
Maybe it’s why, one day, another boss I was working for saw me coding some application or something and told me something like “Oh, you should show me how this stuff is done one of these days”.
I know, quite sad, but you have to look at it with some humor (and detachment xD).
Art does not solve a problem, it communicates ideas and feelings. Potentially a computer program could be a work of art but the act of programming it would just be like the engineering involved in constructing a statue.
Science is research and happens in labs. When you write a program to solve a problem, you are an engineer. You should not be thinking about pushing back the boundaries of human knowledge or expressing your innermost feelings. You should be thinking “What’s the cheapest, most effective way to do this?”.
Software development certainly fails Oscar Wilde’s definition : “All art is useless.” (Oscar Wilde)
On the other hand most OSNews comments are complete and utter art 😉
WTF is the point of wasting time trying to argue this to conclusion? The scope of the endeavor is so vast as to include art, science, engineering, and a truckload of terminological thumb-wrestling, e.g. TFA.
Art, to me, is about expressing a personality, an insane attention to detail, a highly critical self and a nothing-else-matters need to create it.
The selfless people who program entirely as a love of the challenge, and to create something in the best way they can wrap their mind around are artists to me.
Anybody who gets paid to program and programs to get paid is automatically ruled out of creating software as art.
>if the same ratio applied to architects, I’d be afraid to live in a three-storey house, let alone a skyscraper<
Heh, you’ve never worked in the trades have you, most architects are either incredibly stupid, incredably creative with no common sense, or on drugs lol.
Just be thankful the tradesmen have the common sense to fix the architects screw ups (usually).
Anyway, I see a parity here, between the CS (architect) and the programmer (tradesman)
the CS provides the vision and the programmer uses his practical skills to make the program work no matter how effed up the vision is.
For beginner programmers it’s a debate about ART and Science.
When the errors in your program don’t affect MONEY, it can be art to discover on your own Design Patterns you didn’t know about.
As you grow more experienced, and make Mistakes in a Production Environment, where Millions of Dollars of transactions are running thru your system. It becomes a SCIENCE of having the WILLPOWER to code to such a degree of Quality you don’t allow a simple mistake to WIPE OUT YOUR COMPANY.
In other words, If YOU have to meet the CEO to discuss your Mistake, and why it’s costing the company Real Money, then you get the message that it’s not ART anymore.
I think my final thoughts on this matter are…
Computer programming is entirely different from engineering in that the field deals with designing systems on platforms that can vary in various ways. The platforms are based on mathematical systems and logical abstractions.
Where in other forms of engineering the platform is the world; and the world will be what it is today in ten years.
Computer platforms will not.
But Programming isn’t just math either. If you actually tried to use math to check your large program you’d never be able to release it before all of your competitors had made millions off it and moved on to the next thing.
So you end up testing it in a scientific way.
This isn’t to say engineers don’t test things. But I think most of modern testing for engineers is new because of computers. Engineers can only just now design something and test it on the same day, and then repeat that cycle 8 more times.
Even the field of engineering is changing in that sense. Maybe they need to be changing
.
Of course, their tests aren’t 100%. Where testing a program really is 100%. You may not be able to simulate every event; but your events will simulate the same as they will for your customers. Where a simulator will often be slightly off of what will happen in the real world.
Programming has many dynamics that make it very different from engineering. And treating it the same would cripple some of these advantages.
Part of the problem is that memory use and speed is still a big issue most programmers have to worry about, and the best way to handle that is at a low level. But working with the low-level requires a lot of extra work and gives you a bigger chance to f–k up. Therefore, I think most programming is still more of an art than a science.
Once we move further away from low-level programmer and towards more abstract (which I think .Net and WinFX are a good STEP towards) programming, where the programming can more directly apply pseudo-code and ideas to code, it will become more of a science. I’m not sure when this will happen, or even the move will even be very noticable or timely.
Programmers are uncomfortable giving someone else (or the computer) control over optimizations and what have you. As well, hardware is still not fast enough to let us program more abstractly without noticing performance issues. The tools for doing such are still relatively new and have a long way to go.
Most new things start out as an art and move slowly towards a science as the industry refines processes and tools. Where the line will be drawn, I don’t know.
Screw .NET, Lisp interpreters have been doing that sort of thing for ages.
And let me tell you, programming in Lisp is an art just like all programming always will be. Why? Because with a language and environment powerful enough there are a not merely several hundred ways to solve a problem, there are a whole couple dozen that are good enough to actually use on a given problem. However, these numbers aren’t even definite, because people keep coming up with better solutions to problems.
Which is why I think programming is an art. The more powerful the tools your given, the more creative you can be and still achieve good solutions (or bad ones, mind you).
Edited 2006-01-15 04:14
You may be right, I honestly don’t know.
But I don’t think Lisp ever has or ever will catch on like .NET could. Too many parenthesis’.
> And let me tell you, programming in Lisp is an art just
> like all programming always will be. Why? Because with
> a language and environment powerful enough there are a
> not merely several hundred ways to solve a problem,
> there are a whole couple dozen that are good enough to
> actually use on a given problem. However, these numbers
> aren’t even definite, because people keep coming up
> with better solutions to problems.
If you see a dozen different ways to go, it could also mean that you haven’t realized the similarities between them yet, let alone factor them out to leave only a few possible ways to go. How is this different from engineering in other areas?
– Morin
I find the article interesting and at the heart of a conversation that I had with a fellow developer a few days ago. I started my career quite some time ago as an Electrical Engineer but moved to software because I enjoyed it far more. My fellow developer is a CS person who does some good work. It is our approach to problems that usually differs greatly.
My engineering background had taught me to not just jump into working on a solution. I take some time to look at not just the work ahead but how it fits into the bigger picture. With a better understanding of the bigger picture, I can usually come up with an initial architecture that is flexible enough for most future issues. After flushing that out, I start to work on some prototyping to see if what I have envisioned will actually work. With that, then I start to either rewrite the proto code or clean it up heavily and continue on. More times than not, I never have to take any steps back.
My co-worker is just the opposite. He jumps in immediately to coding which means more times than not, he has to take several steps back before he can continue.
Is one approach better than the other? It really depends on what type of problem you are trying to solve. If you take one thing away from this post, please let it be that there is a tremedous difference between an engineers approach to solving problems versus a CS approach. The engineers will typically be more methodical and encompassing more factors.
I started my career quite some time ago as an Electrical Engineer but moved to software
I think that’s a more decisive factor on your observations than the whole CS/engineering discussion. Having seen both kinds of trained SW developers both CS and engineers at work, they are quite alike in their approach. The more methodical approach are more likely to be used by people like you, converted from other fields of engineering like electrical or electronics. As I stated earlier I think it boils down to the mindset created by material and production cost versus recompilation.
Just because something has elegance and an aesthetic does not mean it is an art. In fact when you really think about it and scratch below the surface every profession has an aesthetic and a concept of elegance and clarity. For example take a math proof. There is such a thing as an ugly prrof and a nice proof. Math is not however an art. I think what Pirsig is that people are confusing an ethic of quality with art.
As someone who hates writing proofs because it’s such a vague thing: Writing proofs is definitely an art!
The trouble with the word art is that it’s a minefield. For example, dictionary.com defines it as nonscientific, but goes on to explain that as “Skill that is attained by study, practice, or observation.” Science is definitely big on observation, study, and practice!
In my opinion art is not about beauty but about doing something which requires great skill.
So, factory workers aren’t artists, but even lawyers could be.
This is likely the sort of meaning meant by things like “The Art of …”
But hey, it’s an english word, so it almost doesn’t have a meaning anyway
. It has 16,000 instead!
I think everyone has confused the word art with an ethic of quality; and words are defined by what society believes them to mean. Eventually, at least.
I think there is nothing more beautiful than assembly code when it comes to programming. It has that alien/sci-fi look, yet you wrote it and it works.
Programming in general is also like detective work because of the amount of research you have to do when it comes to protocols and API’s, not to mention debugging. And the satisfaction you get of finally having a correctly working piece of software.
But really, it’s all about coding.
Edited 2006-01-15 05:55
I’ve always seen programming as similar to writing an essay. You have a main objective which you are trying to accomplish, i.e. the thesis. Generally you plan an essay out before writing, much like planning done before coding. The plan tends to be rather general and the details get filled in during the actual process, which is analogous to how most people code. The important thing is stay on task and prove the thesis statement/accomplish the goal in programming. Bad programs and essays tend to wander about without actually staying on point.
In this sense programming is a craft that derives from the art of computer science. Much like crafting an essay derives from the art of writing. I really don’t think programming or computer science fit into the science/engineering boundaries.