|
May 14
2008
|
Programming is not an Art, Science, or Engineering DisciplinePosted by Christopher Diggins in Software Development Methodology and Management, Miscellaneous Musings   |
 |
Jon Erickson posed the question yesterday "Programming Art, Science or Both?", the answer is simple: programming is just an activity.
As programmers we often like to declare ourselves as scientists, engineers, or even artists without appreciating the implications of such pretentitious declarations.
Programming in of itself is just an activity, like brushing your teeth. In the same way brushing your teeth doesn't make you a dentist, writing code doesn't make you an engineer, artist, or scientist.
I think perhaps declaring one's self as a "software engineer" is among the most egregious claims that programmers make. If you are calling yourself a software engineer, perhaps you should ask yourself the following questions:
- Could someone's life depend on the code you write?
- Do you have a degree in software engineering?
- Are you a member of an engineering association?
- Do you have standards to uphold?
- Do you have a professional code of ethics?
- Are you held accountable for your work?
- Can someone reproduce your work, using established processes and the documentation that you created?
- Can you assure that what you have created is correct?
- Do you understand the degree of robustness and reliability of your system?
- Do you perform risk analysis, and understand risk management?
- Are your processes documented?
These are the kinds of things that most of us expect from people who have a professional title of "engineer". However, for most programmers, the answer to the majority these questions is no. So should we really be calling ourselves engineers?
Comments (18)
Subscribe to this comment's feed
Show/Hide comments
written by Jon Erickson, May 14, 2008
Here's what Nevil Shute -- my favorite novelist and an engineer to boot -- had to say about an engineer:
"An engineer is a man who can make something for five bob that any bloody fool can make for a quid!"
And for those who don't know the difference between a bob and a quid, here's what wikipedia says: "a quid was one pound sterling and five bob was one quarter of a pound".
"An engineer is a man who can make something for five bob that any bloody fool can make for a quid!"
And for those who don't know the difference between a bob and a quid, here's what wikipedia says: "a quid was one pound sterling and five bob was one quarter of a pound".
written by James Merritt, May 14, 2008
Back when I was at Berkeley (mid-1970s), they were actually trying to train software engineers, who were fully aware and capable of living up to the various criteria you list above. Unfortunately, the plan was based on the idea that programs could be proven correct. When it became clear that we just weren't there yet, and might not ever be, enthusiasm for satisfying the rest of the criteria waned in step with accelerating demand for coders.
I think that those who are aware of and do their best to satisfy your criteria can legitimately be called "software engineer." But their success or failure to satisfy those criteria would mark them as "better" or "worse" engineers, respectively. In my opinion, even a bad engineer is better than a great software "artist," when it comes to generating software upon which people must depend (as opposed to, say, games or entertainments). Being a software engineer is about much more than the coding, something they kept telling us back at Berkeley. But looking at the development of the industry since then, I have to wonder, who listened?
A "software artist" is someone who slings the code as a bravura act of personal expression, delivers the object, and then challenges you to "deal with it"; there are plenty of such programmers in the business. Perhaps most code written during the personal computer era was "software art" in that sense. It wasn't well-tested, it's design was haphazard and not well vetted or understood, the limits of its robustness could not be described, and the internal workings were practically impenetrable when maintenance was necessary.
I think the term "Developer" became popular precisely because "programmer" seemed too lower-caste and restrictive, while "software engineer" left the user too vulnerable to the kinds of sneering and challenge to professional status that you engage in above. (Not that sneering isn't an appropriate response to poseurs, albeit unkind to well-meaning but flawed aspirants to the title.)
I think that those who are aware of and do their best to satisfy your criteria can legitimately be called "software engineer." But their success or failure to satisfy those criteria would mark them as "better" or "worse" engineers, respectively. In my opinion, even a bad engineer is better than a great software "artist," when it comes to generating software upon which people must depend (as opposed to, say, games or entertainments). Being a software engineer is about much more than the coding, something they kept telling us back at Berkeley. But looking at the development of the industry since then, I have to wonder, who listened?
A "software artist" is someone who slings the code as a bravura act of personal expression, delivers the object, and then challenges you to "deal with it"; there are plenty of such programmers in the business. Perhaps most code written during the personal computer era was "software art" in that sense. It wasn't well-tested, it's design was haphazard and not well vetted or understood, the limits of its robustness could not be described, and the internal workings were practically impenetrable when maintenance was necessary.
I think the term "Developer" became popular precisely because "programmer" seemed too lower-caste and restrictive, while "software engineer" left the user too vulnerable to the kinds of sneering and challenge to professional status that you engage in above. (Not that sneering isn't an appropriate response to poseurs, albeit unkind to well-meaning but flawed aspirants to the title.)
written by Mark Nelson, May 14, 2008
>Unfortunately, the plan was based on the
>idea that programs could be proven correct.
One of the all-time great ideas in Computer Science that so far fails to scale. Much like the climate simulation guys in Swaine's post from a few days back: just give us more FLOPs and we'll lick this problem for sure!
It's funny that such an enormous part of our livelihood is spent simply trying to make sure that our creations do what we want them to do. Imagine what the world would be like if you hired a guy to mow your lawn, sight unseen, and he only had a 50% chance of getting it right the first time? And in 10% of the failure cases he actually burns down your house?
- Mark
>idea that programs could be proven correct.
One of the all-time great ideas in Computer Science that so far fails to scale. Much like the climate simulation guys in Swaine's post from a few days back: just give us more FLOPs and we'll lick this problem for sure!
It's funny that such an enormous part of our livelihood is spent simply trying to make sure that our creations do what we want them to do. Imagine what the world would be like if you hired a guy to mow your lawn, sight unseen, and he only had a 50% chance of getting it right the first time? And in 10% of the failure cases he actually burns down your house?
- Mark
written by Jonathan Wise, May 14, 2008
Could someone's life depend on the code you write? Absolutely
Do you have standards to uphold? Absolutely
Are you held accountable for your work? Absolutely
Can someone reproduce your work, using established processes and the documentation that you created? Absolutely
Can you assure that what you have created is correct? Usually, and with help from the Quality team
Do you understand the degree of robustness and reliability of your system? Usually
Do you perform risk analysis, and understand risk management? Absolutely
Are your processes documented? Absolutely
If brushing your teeth required extensive training, a rigorous process, and the product of the teeth brushing process were used by hundreds of people every day, then I would agree with you, yes, programming is just like brushing your teeth.
But since brushing your teeth has none of those attributes, and since most professional software developers should be able to answer yes to the majority of those question, I can't agree with you at all.
Do you have standards to uphold? Absolutely
Are you held accountable for your work? Absolutely
Can someone reproduce your work, using established processes and the documentation that you created? Absolutely
Can you assure that what you have created is correct? Usually, and with help from the Quality team
Do you understand the degree of robustness and reliability of your system? Usually
Do you perform risk analysis, and understand risk management? Absolutely
Are your processes documented? Absolutely
If brushing your teeth required extensive training, a rigorous process, and the product of the teeth brushing process were used by hundreds of people every day, then I would agree with you, yes, programming is just like brushing your teeth.
But since brushing your teeth has none of those attributes, and since most professional software developers should be able to answer yes to the majority of those question, I can't agree with you at all.
written by Christopher Diggins, May 14, 2008
@Mark Nelson: I would argue, that an engineer in another discpline, would answer yes on virtually everything. No maybes.
"writing programs is done very much like writing novels"
This is very true I think. I also agree that most programming is fun today, but fun and relevant don't really go hand in hand.
@Jon Erickson: Nice quote. I'll counter by saying that the people designing our cars and airplanes are not bloody fools, and are definitely not designing software the way people implemented certain operating systems that best not be named. To answer your post title: I am not qualified to say what an engineer really is. I just know it isn't me, nor is it the guy in the next cubicle.
@James Merrit: "I think that those who are aware of and do their best to satisfy your criteria can legitimately be called "software engineer."
I think this is a very reasonable statement. I just don't think we can let people decide for themselves, otherwise we will continue to get unreliable software.
@Jonathan Wise: Programming doesn't require extensive training, nor a rigorous process. Sometime people follow rigorous processes, and perhaps they are engineers, however most do not, and most are not.
"writing programs is done very much like writing novels"
This is very true I think. I also agree that most programming is fun today, but fun and relevant don't really go hand in hand.
@Jon Erickson: Nice quote. I'll counter by saying that the people designing our cars and airplanes are not bloody fools, and are definitely not designing software the way people implemented certain operating systems that best not be named. To answer your post title: I am not qualified to say what an engineer really is. I just know it isn't me, nor is it the guy in the next cubicle.
@James Merrit: "I think that those who are aware of and do their best to satisfy your criteria can legitimately be called "software engineer."
I think this is a very reasonable statement. I just don't think we can let people decide for themselves, otherwise we will continue to get unreliable software.
@Jonathan Wise: Programming doesn't require extensive training, nor a rigorous process. Sometime people follow rigorous processes, and perhaps they are engineers, however most do not, and most are not.
written by James Merritt, May 15, 2008
Mark wrote, "It's funny that such an enormous part of our livelihood is spent simply trying to make sure that our creations do what we want them to do."
And also that so little of our livelihood seems to be spent understanding exactly what we want them to do (or what our customers want them to do). A big part of the problem of the non-scalability of software correctness proof comes from the chronic lack of precise specifications. A proof has to be based on requirements, rigorous expectation of function, reliable assumptions about operating environment, etc. So much of software is created by guessing about what the right thing to do is: seat of the pants design. Formal specs are so often descriptions of the shipping code's functionality, created after the fact, if they ever get written at all.
Of course, as we enter the realm of massively multi-threaded apps, the onetime goal of correctness proof moves further out of reach. It was hard enough to prove that a deterministic, sequential program of any interesting size was correct. How much harder to prove that a system of independently executing processes, each containing perhaps many parallel threads, will do the right thing?
As it seems to me, software development is perhaps at the stage today, where architecture and building construction were in the time of Hammurabi: An art married to a reasonably mature craft. But even in that time, the code of Hammurabi demanded that if a builder's house should collapse and kill the owner, the builder should be put to death. Whenever I was responsible for multi-developer software projects, I always tried to make the team aware of what real accountability was.
And also that so little of our livelihood seems to be spent understanding exactly what we want them to do (or what our customers want them to do). A big part of the problem of the non-scalability of software correctness proof comes from the chronic lack of precise specifications. A proof has to be based on requirements, rigorous expectation of function, reliable assumptions about operating environment, etc. So much of software is created by guessing about what the right thing to do is: seat of the pants design. Formal specs are so often descriptions of the shipping code's functionality, created after the fact, if they ever get written at all.
Of course, as we enter the realm of massively multi-threaded apps, the onetime goal of correctness proof moves further out of reach. It was hard enough to prove that a deterministic, sequential program of any interesting size was correct. How much harder to prove that a system of independently executing processes, each containing perhaps many parallel threads, will do the right thing?
As it seems to me, software development is perhaps at the stage today, where architecture and building construction were in the time of Hammurabi: An art married to a reasonably mature craft. But even in that time, the code of Hammurabi demanded that if a builder's house should collapse and kill the owner, the builder should be put to death. Whenever I was responsible for multi-developer software projects, I always tried to make the team aware of what real accountability was.
written by Jim Wilcox, May 15, 2008
I blogged about the art and science of programming the other day...
http://politechnosis.kataire.c...ience.html
http://politechnosis.kataire.c...ience.html
written by ALEXEI POLKHANOV, May 15, 2008
Well, these are the questions I asked myself many times.
I know many people who would answer yes to most of the questions. There are professional organizations like IEEE with code of ethics, standards such as ISO 12207. Obviously if software engineering is to became _real_ regulated engineering profession all developers will have to form professional organization and require mandatory certification. Problem is that not engineers - software industry itself is not ready for this and customers not willing to bear the costs.
I know many people who would answer yes to most of the questions. There are professional organizations like IEEE with code of ethics, standards such as ISO 12207. Obviously if software engineering is to became _real_ regulated engineering profession all developers will have to form professional organization and require mandatory certification. Problem is that not engineers - software industry itself is not ready for this and customers not willing to bear the costs.
written by David Snook, May 15, 2008
I read something the other day that really resonated with me. It was a quote from Avram Miller of Intel, who said, "We are toolmakers, not artists." (I read it in "Software For Use" by Constantine and Lockwood, page 5.)
The software products we make are tools for others to use. Our tools are unique in that they are tools for the mind, extending the reach, or capacity, or exactitude of the mind, but they are still just tools.
Our tools are used to "extend" the minds of artists, engineers, and scientists, but that doesn't make us any of those things ourselves. We have to understand these disciplines enough to build tools for them, and in a way we have to be a little bit of all of them, but we are still one step removed from each of them.
We also create tools for many other disciplines and tool users. We write software for used car salesmen and politicians, but we don't feel the need to say that we are money-grubbing con-men. Or that we sell cars.
The software products we make are tools for others to use. Our tools are unique in that they are tools for the mind, extending the reach, or capacity, or exactitude of the mind, but they are still just tools.
Our tools are used to "extend" the minds of artists, engineers, and scientists, but that doesn't make us any of those things ourselves. We have to understand these disciplines enough to build tools for them, and in a way we have to be a little bit of all of them, but we are still one step removed from each of them.
We also create tools for many other disciplines and tool users. We write software for used car salesmen and politicians, but we don't feel the need to say that we are money-grubbing con-men. Or that we sell cars.
written by Mark Nelson, May 15, 2008
Jack Ganssle weighs in on embedded.com:
http://www.embedded.com/column...tid=145742
I think his perspective is a bit skewed from the average person reading this.
http://www.embedded.com/column...tid=145742
I think his perspective is a bit skewed from the average person reading this.
written by Christopher Diggins, May 15, 2008
Great link Mark, thanks! I think Jack is probably an engineer by any accounts, and is surrounded by engineers. It sounds to me like he bristles about being called a "programmer" without realizing that some of us are exactly that.
It is interesting that he thinks coding is easy. Coding is actually very hard. People who think coding is easy don't really care much about the code itself, and the craft of writing good code (this is why for people writing the relaible code it is so damn expensive). However, engineering reliable software systems, has nothing to do with being able to write elegant code. I envy and admire those people who create reliable software systems, but I hate using their code.
@James: I agree very much with what you have to say on the subject. However for the most part we are living before the time of Hammurabi: there is little real accountability for software developers. This is simply because people know better than to let software developed by non-engineers. To be blunt, there is a good reason why certain operating systems would never be used to fly airplanes. I think it is very telling that in the embedded computing industry less only 13% had a computer science degree. I interpret this to indicate that computer scientists don't automatically make good engineers.
@Alexei: I agree the market isn't ready. I think though that the cost of writing reliable code will come down, especially when people in computer science and software engineering starts to cooperate.
It is interesting that he thinks coding is easy. Coding is actually very hard. People who think coding is easy don't really care much about the code itself, and the craft of writing good code (this is why for people writing the relaible code it is so damn expensive). However, engineering reliable software systems, has nothing to do with being able to write elegant code. I envy and admire those people who create reliable software systems, but I hate using their code.
@James: I agree very much with what you have to say on the subject. However for the most part we are living before the time of Hammurabi: there is little real accountability for software developers. This is simply because people know better than to let software developed by non-engineers. To be blunt, there is a good reason why certain operating systems would never be used to fly airplanes. I think it is very telling that in the embedded computing industry less only 13% had a computer science degree. I interpret this to indicate that computer scientists don't automatically make good engineers.
@Alexei: I agree the market isn't ready. I think though that the cost of writing reliable code will come down, especially when people in computer science and software engineering starts to cooperate.
written by James Merritt, May 15, 2008
C Diggins wrote, "I think it is very telling that in the embedded computing industry less only 13% had a computer science degree."
Yeah, and I read once that Modula-2 was pretty popular in embedded computing, too. Leave it to those unwashed heathens without CS degrees to choose excellent tools that "real" computer scientists publicly eschew.
For the record, I don't have a CS degree either. Perhaps this puts me closer to being an actual Software Engineer, or at least to being able to evaluate programming tools without succumbing to the mind-addling fog of industry fad and fashion. I hope so, anyway.
As far as OSs that aren't safe to use in avionics systems, I'm frankly scared bitless to think that Microsoft code of ANY kind may someday be built into my automobile.
Yeah, and I read once that Modula-2 was pretty popular in embedded computing, too. Leave it to those unwashed heathens without CS degrees to choose excellent tools that "real" computer scientists publicly eschew.
For the record, I don't have a CS degree either. Perhaps this puts me closer to being an actual Software Engineer, or at least to being able to evaluate programming tools without succumbing to the mind-addling fog of industry fad and fashion. I hope so, anyway.
As far as OSs that aren't safe to use in avionics systems, I'm frankly scared bitless to think that Microsoft code of ANY kind may someday be built into my automobile.
written by Mark Nelson, May 16, 2008
>without succumbing to the mind-addling fog
>of industry fad and fashion
Hey, I just finished a 26-year journey to getting my *2nd* CS degree, and I'll hear no more talk like that! My employer paid good money for that sheepskin.
- Mark
>of industry fad and fashion
Hey, I just finished a 26-year journey to getting my *2nd* CS degree, and I'll hear no more talk like that! My employer paid good money for that sheepskin.
- Mark
written by Andy Barnhart, May 21, 2008
It's physics with fudge factors.
I am not an engineer, nor a physicist. I write code. I used to manage other people who write code, but I didn't like that as well (when you fix problems in code, they stay fixed ). I really don't care much about what the title is - programmer, software developer, code monkey or whatever, but I do understand why professionals (those in fields where they have high standards and must pass tests like doctors, lawyers, CPAs, pilots and engineers) who worked hard to get the title can take offense at it being assumed by others with no credentials.
I am not an engineer, nor a physicist. I write code. I used to manage other people who write code, but I didn't like that as well (when you fix problems in code, they stay fixed
). I really don't care much about what the title is - programmer, software developer, code monkey or whatever, but I do understand why professionals (those in fields where they have high standards and must pass tests like doctors, lawyers, CPAs, pilots and engineers) who worked hard to get the title can take offense at it being assumed by others with no credentials. written by Austin Chambers, May 21, 2008
Programming is a craft. Much like constructing a violin is a craft. Is it an art? No, there are a set of rules which must be followed. "Art" has the freedom to break these rules. Is there a science to it? Yes, if you *use* science to do it.
Is it engineering? Not by itself. "Engineer" is defined as "One who is trained or professionally engaged in a branch of engineering." Programming is not a branch of engineering. However, "engineer" is also a title. If one has a degree in engineering then they are an engineer. Simple as that.
A software engineer is a software developer that has a degree in engineering.
Software Engineers are a subset of Software Developers.
Software Developers are a subset of Programmers.
They are not all the same.
Is it engineering? Not by itself. "Engineer" is defined as "One who is trained or professionally engaged in a branch of engineering." Programming is not a branch of engineering. However, "engineer" is also a title. If one has a degree in engineering then they are an engineer. Simple as that.
A software engineer is a software developer that has a degree in engineering.
Software Engineers are a subset of Software Developers.
Software Developers are a subset of Programmers.
They are not all the same.
written by ranjix _, May 21, 2008
in the following text I'll assume programmer == BS in CS or CE. if you talk about something else, then please specify.
so, my 2 cents:
1. you put engineers on a very high pedestal. even if - in theory - they pass your little questionnaire, in reality I believe that they are of all kinds (and a long history of accidents should be proof). just like "programmers".
2. "programming in of itself is just an activity, like brushing your teeth". really? how many years do you have to study "brushing your teeth" to pass the final "brushing your teeth" exam?
3. programming has a lot more in common with engineering (which implies clear purpose and tinkering) than with "art" (expressing oneself as purpose) or "science" (study of a certain subject with or without a clear purpose).
4. although programming is close to engineering, programming doesn't have "tradition" - processes and tools themselves tend to change a lot faster than in engineering.
5. as a mantra, programming says "don't repeat yourself", engineering says the exact opposite.
6. from an ethical/professional POV, the only serious difference I see between the programming and engineering is the one related to reliability. if there were more constraints on software to be reliable, IMO one would see a lot fewer "knight coders" than there are.
7. both engineering and programming pay their dues to the (and are victims of) "business sense". everything becomes a trade-off between cost, quality and time.
and a question for you - complexity-wise, what is more complex, a car or an application? toyota prius or photoshop? mclaren or windows os? If you are of the same opinion as I am, you might start understanding why there are - in general - a lot more bugs in software than in hardware/engineering, which reflects poorly on the "activity".
so, my 2 cents:
1. you put engineers on a very high pedestal. even if - in theory - they pass your little questionnaire, in reality I believe that they are of all kinds (and a long history of accidents should be proof). just like "programmers".
2. "programming in of itself is just an activity, like brushing your teeth". really? how many years do you have to study "brushing your teeth" to pass the final "brushing your teeth" exam?
3. programming has a lot more in common with engineering (which implies clear purpose and tinkering) than with "art" (expressing oneself as purpose) or "science" (study of a certain subject with or without a clear purpose).
4. although programming is close to engineering, programming doesn't have "tradition" - processes and tools themselves tend to change a lot faster than in engineering.
5. as a mantra, programming says "don't repeat yourself", engineering says the exact opposite.
6. from an ethical/professional POV, the only serious difference I see between the programming and engineering is the one related to reliability. if there were more constraints on software to be reliable, IMO one would see a lot fewer "knight coders" than there are.
7. both engineering and programming pay their dues to the (and are victims of) "business sense". everything becomes a trade-off between cost, quality and time.
and a question for you - complexity-wise, what is more complex, a car or an application? toyota prius or photoshop? mclaren or windows os? If you are of the same opinion as I am, you might start understanding why there are - in general - a lot more bugs in software than in hardware/engineering, which reflects poorly on the "activity".
Write comment
Show/Hide comment formYou must be logged in to a comment. Please register if you do not have an account yet.
At the current state of maturity, writing programs is done very much like writing novels, and we don't call novelists Story Engineers.
When the discipline becomes more like building bridges or planning highways it will probably earn the Engineering title, but maybe it will be less fun then.
- Mark