Wednesday, January 23, 2008
Ratcatchers and Engineers
Ever wondered if what you are doing is (software) engineering? Here is a heuristic.
If you don't use mathematics in your day to day work, you aren't (an engineer). All engineers (say those who build bridges, or space craft, or cars) make heavy use of mathematics and/or hard sciences like Physics on a regular basis.
Now, not being an engineer is ok. Being a carpenter or a plumber is a perfectly honorable choice as is being a musician or actor or teacher. If you enjoy being a carpenter/plumber/automobile mechanic, more power to you. You should do what makes you happy and puts bread on the table. That said, a craftsman is not an engineer. The guy in the garage who fixes your engine is not an automobile engineer who could design the next generation car. Not close.
This insight was triggered by Raganwald's "No Disrespect" blog post. I quote
...Let me tell you the cold, hard, truth. You aren’t going to like this, but I ask you to believe me when I say that I am telling you this for your own good:
There is a culture of pretending business programming is more than it is. Some of you calling for more Java in University may take false hope that I am on your side. You may think that the people arguing for Scheme, Haskell, and OCaml are elitists. Wrong. They do not have a problem. You are the one with a problem because you don’t want to tell all your friends you have a job as a clerk.....
We all know what the typical software "engineer" job ad looks like. A job ad for a real engineer would look like this. (Noe the absence of "10 years in java/dotNet/Ror" type crap. Note that he explicitly asks for a Phd (and tell you under what circumstances he will waive it)
The distinguishing trait of an engineer (and Werner's job description explicitly ask for this) is that he builds and works with mathematical models to design a real world effect or system. They also use other tools(simulations, prototypes, experiments etc) but (mathematical) modeling is key. A scientist,as distinct from an engineer, uses roughly the same tools to advance the state of knowledge without necessarily affecting the real world. The borders are fuzzy. You have scientist-engineers and engineer-scientists, as well as people who focus on "pure"
science or engineering.
"Modeling" is a deep topic. Read the book I've referred to at the end of this blog for examples of how this works. Suffice to say If I am not building (say) algorithmic models to help me decide how to build my software, or to generalize, if I am not using "theory" on a day to day basis, I am not *engineering* anything. Modeling has a very precise meaning in Engineering and Science. (No, UML diagrams, or "story cards" are not engineering artifacts no matter what the methodology vendors say ;-) ).
Enterprise software is the least amenable to the modeling/engineering approach. There are exceptions but most "enterprise" developers are the equivalent of clerks, as Raganwald so eloquently points out. There is nothing wrong with being a clerk as long as you know you are one and are not deceiving yourself. Most enterprise software projects, in keeping with their clerical nature, are life draining. But hey if you like it, go for it.
Another friend of mine, who is a very talented programmer (he recently moved away from enterprise app development) , when asked why he changed the focus of his career, told me,(paraphrased) "Humanity has only a very limited amount of talented people. It is a crime against humanity to employ that talent to bug fix enterprise applications or futz around with Ruby On Rails deployment issues. I want to do something meaningful". (As you can see I have interesting friends :-) ).
To conclude, the title "Software Engineer" is (most of the time) a particularly deceptive one. To be accurate it should something like "Software Maintenance Worker" or "Software Handyman", but I guess it is easier to hire someone if his job title is "Rodent Officer" instead of "Ratcatcher".
.
PS:- Please, before anyone feels offended and sends me hate mail or snarky comments, please read (something like) "The Idea Factory - Learning to Think at MIT". (This was the book that jolted me out of my complacency and set my feet firmly on the research/engineering path). Then actually think about it :-). Either be happy as a rat catcher or do something about it.
[This is the first in a series of four blog posts. Read part two and part three]
Subscribe to:
Post Comments (Atom)
41 comments:
"Either be happy being a rat catcher or do something about it."
Thanks for that kick in the a**. I am one of the enterprise dev drones in Bangalore.
I always had this vague feeling that what I do day to day (ASP dot net!!!) not what programming is all about but this blog entry is exactly what I needed to spur me to action.
I'll be attending DevCamp! I look forward to your session (on monads?).
Oh come on! Software Engineers merit the title "dog catchers" at the very least, if not the loftier "cow herds".
Ravi, The link to the book is broken.
@binil,
Thanks! Fixed.
your definition of engineer is too narrow. it think the many folks who had their hands in building emacs, apache httpd, the linux kernel, etc are all examples of great engineers. while those endeavors have their share of nontrivial algorithms to write and analyze they are not the mathematical puzzles you claim make an engineer.
there are all kinds of software engineers. your litmus test does nothing to sort them out.
Aho my friend ...
"To be accurate it should something like "Software Maintenance Worker" or "Software Handyman", but I guess it is easier to hire someone if his job title is "Rodent Officer" instead of "Ratcatcher".
I loved that !
Click .. Click ..
I love anonymous morons who can't argue logically.
the structure of your argument goes like this
1.I don't agree with your (Ravi's) definition of "engineering"
2. I select some people who write good software (Torvalds, Stallman etc) and claim that they are good "engineers", without ever defining engineering or distinguishing "good" from "engineered".
3. I (the anonymous person) claim that this invalidates your (Ravi's) argument.
Umm. to invalidate an argument, a "claim" is not enough. Try understanding some logic first?
Spotted the flaw yet?
Here is a hint. I made no claim that engineered software == good software or (by commutativity) good software == engineered software.
You can write good software without engineering it. ThoughtWorks for example is full of people who write good enterprise software. That doesn't make the process of creating that software "engineering".
more genrally, Mozart was not engineering Music when he wrote all those lovely operas. Shakespeare wasn't engineering his dramas.
Excellence != engineering.
Read the blog post carefully and respond to what *I* say, not what the voices in your head (and your emotions) tell you I'm saying.
Ravi, I think saying "No developers are engineers" is as misleading as "All developers are engineers". For the most part I agree with your definition, and most of your statements. However there are cases when your definiton of engineer perfectly describes how software is made.
I'll provide a few examples from the last year. During that time period my tasks have included:
Making the communications layer work with a new feature. (not engineering)
Making a webpage to display stats on customers (not engineering)
Creating an ip traffic flow control system (qos stuff, ratelimiting, etc). (engineering, involves applying queueing theory, which is math. I created a model using queueing theory. Of course in software the model is the result...)
Creating support structures to apply above model per user and system (fuzzy between engineering and not).
Text parsing improvements from a naive approach to a fast in depth approach. Used knowledge of algorithms and models to find get a good result. (maybe engineering, since it involved discreet math)
Customer registration process and db work (definately enterprise, definately not engineering)
Given the above examples, and doing my best to assess fairly on your definition, do you still think all software is not engineering?
PS I'm willing to grant that your position is not that "all software creation is not engineering", but thats the way it reads.
Erich,
You say
"I think saying "No developers are engineers" is as misleading as "All developers are engineers" ".
I agree! But since I never claimed either, I don't see the point of disagreement.
What I am saying is that most software development effort is not engineering (and so "Software Engineer" is mostly a deceptive job title).
Which is almost exactly what I hear you saying. (You say "all". I say "most")
There is no engineering without (applied) mathematics. And most software development efforts don't use mathematics. Craftsmen or artists don't necessarily work with (non elementary) mathematics.
If most software development does not need maths (or mathematical modeliing, to be more precise), then most software development is not engineering. Which is what I said.
I guess the difference between our view points centre on the difference between "most" and "all"? Since I never made an absolute claim, I can't figure out how you heard "all"?
I am NOT saying that "**all*** software development efforts are not engineering".
I explicitly linked to a software *engineering* job description (Werner Vogels's job "ad").
In the blog post I say,
"To conclude, the title "Software Engineer" is (most of the time) a particularly deceptive one."
So how did you read me saying "*ALL* software is not engineering"?
I said "most of the time software dev is NOT engineering". Which I think is what you are saying?
I agree that most uses of "software engineer" are absurd, but I'm confused by your endorsement of its use for work involving daily math "and/or" physics. As long as there is one lauded position for a software "engineer" at Amazon, there will be thousands at Google and hundreds of thousands at wanabee corporations. What distinguishes traditional engineering in my outsider view (being a programmer) is its concern with physical structures. It necessarily involves applying both math and physics as the best tools humans have come up with to design them. I don't see how software programming, even for the top job at the top online store, is or should aspire to be that.
Ravi,
Reading your reply to my post, and rereading the artilcle in light of that post. We are on the same page.
I think it comes down to terminology. As I described, I do engineering work, and I do craftsman work in rougly equal doses. My title is "Systems engineer". Its the same title as the guy at the next desk over who makes web widgets for the framework we use. His job is far more of a design job (in a graphical design sense).
Nick Malik posted a similar issue regarding the term Architect on his blog. (sorry no link, but it was from May or June 2007. Im starting to wonder if as an industry, we should sit down and define some things.
regards,
Erich
@Erich,
I *think* all Ravi is saying is "There is no engineering discipline which does not require extensive use of Applied Mathematics".
(Ravi, correct me if I got this wrong)
Granted that premise, all else follows.
Ravi also took care to (a) leave open the possibility that engineers use other tools besides mathematics (b) even given (a), mathematics remains an indispensable part of all engineering.
The easy way to disprove the *premise* (which is the only way to attack this argument, since the logic is fairly watertight) is to find an example of an engineering discipline that does not use mathematics at all or only sparingly uses mathematics (and where most engineers in that discipline are ignorant of mathematics).
Your examples seem to be in harmony with the blog post.
When you use queuing theory or discrete math to achieve a real world effect, you are acting as an engineer. When you are writing a webpage, not so much.
Now all scientists (I am one) and engineers do things which don't involve mathematics. The question is "Is Applied Mathematics a *core* component of what you do?". Most engineers (and scientists) would answer in the affirmative. Most software developers would answer in the negative.
From your task list it certainly does seem that most of your work was *not* mathematical.
Ravi's claim seems to be that most software developers (let's say , oh, 90 % if we want a number) don't use mathematics in any significant amount in developing software.
So yes, *by and large*, software development does not seem to be an engineering discipline in the sense Mechanical engineering or Electrical Engineering is.
There are exceptions (Ravi points to one such). I am sure Google does a lot of algorithmic analysis, queueing theory etc for their search engine or the Google File System (perhaps not so much for the java script in Gmail).
Which sounds about right to me. But then what do I know? I am physicist. :-)
@Ravi,
Another brilliant post. It is a pleasure to read a well thought out and consistent piece of writing. Even when I disagree (in this case I don't) I am forced to elucidate why and I learn from it.
I am fascinated by how your "persona" switches from blisteringly harsh( "anonymous morons who can't think logically" !! ouch! ) to eminently reasonable!
Why do I have this strange idea that you would make a great actor? ;-)
@joe
Id say that my particular job is mostly in the engineering catagory. I guess it depends on if you count by number of tasks, in which case you are right. If you count by time spend, well over 3/4 of the last year has been spend on the ip traffic shaping code (the engineering bit).
aargh! too many comments for me to reply in any great detail (and it is almost midnight here in Bangalore)
@Joe,
You said it better than I could. So when are you starting your own blog?
As for persona .. "All the world's a stage .. " ;-)
@code,
Hey I LOVE your blog! Welcome!
"Physical structures" is an interesting argument. But it doesn't follow that the use of maths is bound to that. I am a (Mechanical) engineer *and* a programmer, which maybe why I have a different perspective.
Engineering is not only about phsyical structures (or rather it doesn't always work in terms of physical structures). Take Digital Signal Processing. Even when you abstract the underlying physical details away, and deal with "pure" signals and sine waves there is a lot of mathematics involved for a signals engineer(or electronics engineer if you prefer) who is designing a radar (say) to work through.
And conversely, even the most abstract algorithm has to be embodied in hardware to work. Whether an algorithm is baked into hardware or remains software doesn't change the (absence of) significant mathematical sophistication required to conceive and implement it.
What is hardware vs software is often a historical/economic choice than an essential difference.
If you see my reply to Erich, you'll probably get a clearer picture of what I am trying to say (Mea culpa I should write clearer prose).
I suspect we agree more than disagree (but feel free to disagree!)
Cheers,
Ravi
Cow herds? Pshaw... where do you work? Cow herding is easy. What *I* do is _CAT HERDING_. Most more difficult and prestigious.
Yes, signals make a good example that falls outside my layman's "Gustave Eiffel" idea of engineering. But signals are still deep in physics, right? I like your argument quite a bit, but I want to take it in the strong "math and physics" form rather than the and/or you've proposed. In my opinion even Mr. Vogels could do better to advertise for a "Senior Software Researcher", which is clearer than the title given (and just as prestigious, to anyone that counts). The only "software engineers" would be those working on software that models or intertwines with the physical world (including signals) and thus depends on physics (and math). It's not so much an honor as a category. Then you'd avoid this bickering over how much math is enough math, or the right kind of math. You'd lose, I guess, a distinct label for higher order mathy programming, but I'm not sure that such a label is helpful, and I'm darn sure it will be defensively claimed by everyone anyway. ;)
Hey, you're the guy that linked to me from Sliding into Scala! I'm subscribing to your weblog for real now.
I personally think it's incorrect to say that engineers use a lot of math or physics in their daily work. I know a civil engineer who works on the city traffic system. He uses software packages for analysis and simulation, but he doesn't do math or physics much if at all. Another engineer works for the city on the water and sewer pipeline system. Again, not much if any direct use of math or physics in daily work. I have one more friend who designs HVAC (heating/ventilation) systems. I will have to ask how much math/physics he uses on a daily basis, but again I doubt it's a whole lot. Finally I know one more engineer who works for a company that makes compressors for gas pipelines. They do use some math formulas, but they just plug them in in a fairly trivial way. While I am sure there are engineers who use math and physics more than that, I doubt the every day average engineer uses these tools much any more - if they do it's by plugging numbers into a calculator or software system which does the real work. I personally don't have any desire to call myself a software engineer, but it's worth stating that "real" engineers rarely do deeply creative or fundamental work. I once asked a recent electrical engineering grad to explain to me what a transister was and she couldn't. Sad but true. I remember reading Surely You're Joking Mr. Feynman. During the war he worked with some mechanical engineers. He was delighted to discover all he needed to do was to know a little about gears and choose the ones in the "middle" to avoid problems - and he could be a mechanical engineer! :)
I agree, most software development is not software engineering. I dont necessarily agree, as someone else alluded earlier, however, with your definition of engineering. Mathematics seems to me to be a possible method or tool by which engineers are able to model the physical world. Where a software engineer my use other methods to model the problem they are solving.
Engineering seems to me to be akin to the scientific method where you use a systematic approach to solving a problem using set parameters or criteria and proven methods or solutions.
Using mere math shouldn't be the criteria for what is engineering. I hardly consider developing algorithms as engineering unless there is a method and model behind the development or the algorithm is part of a larger project.
This post is accurate conceptually, but rhetorically over-cooked.
The reason people started referring to programmer as "software engineers" was political. Referring to them as "clerks" is also a political act.
If the average software engineer's job does not involve extensive mathematical modelling, why not refer to them as "symbolic designers", or "logical drafters"?
Once you scrape away the veneer of tough talk here there's not that much substance left. A name is just a name.
Yes, this is sad but true - software development ain't no engineering ( aside from embedded and real-time stuff which is probably more Electrical Engineering anyway).
It pays bills but enterprise software is not a rocket science and few non-CS graduates would argue against this statement. One does not need a degree to be a developer, even a very good one.
As a side note, for many people even what is called SE is rarely seen in real life - at most CVS and Ant.
What about locomotive engineers? http://www.ble.org/
What kind of abstract mathematical modelling do they develop?
I see engineering as using the understanding of some theory to design and build a system.
the reason of using the theory is that enables you to design more optimal systems then without knowing the theory.
usually in the physical world - theories are expressed in mathematical terms so building mathematical models is a very usefull tool for designing systems in the physical world.
but in software (and in some other places - for example digital hardware design ) mathematical models just don't have much use. so people use other tools and models to bridge the gap from theory to practice.
so what are the theories needed in software design?
1.theory of the problem we want to solve = specification(and theory of how to get specification from people)
2.theory of UI design
3.theory of system design or how to architect a system
4.theory of telling the computer what to do in efficent manner.
etc...
and using those theories models are being built :
1.UML models
2.UI screens
3.prototyping some parts of the software
so i do believe software designers are still "engineers" even though they don't use math.
regarding software developers :
the distinction builder/engineer is a continous one , i think.
so some programmers who just churn specifications into code without much thought are more of builders , and some , who know the many theories needed in order to write great code(for example design patterns,how to write clean code,understanding memory allocation ,understanding the sql engine etc..) are more like engineers.
and what is their model ? usually the code is the model.
I don't have much free time today, but quickly,
,
@dharh
"Mathematics seems to me to be a possible method or tool by which engineers are able to model the physical world."
This is exactly what I said. But applied mathematics is at the core of engineering disciplines. That's not true for software dev. You can have a software developer who doesn't know any maths at all.
@anonymous(1),
Thanks for the "locomotive engineers"(aka train drivers) link.
@anonymous(2)
"The reason people started referring to programmer as "software engineers" was political. Referring to them as "clerks" is also a political act.
If the average software engineer's job does not involve extensive mathematical modelling, why not refer to them as "symbolic designers", or "logical drafters"? "
This is BRILLIANT! I love "logical drafters". MEthinks thou see-eth politics where it is not intended, but it is a VERY interesting concept! I have no argument with "logical drafters". It is a good description of what most sw devs do.
"Rhetorically Overcooked"? heh heh. WHat makes you think it was anything but intentional?
@anonymous(the last one before this comment). You my friend are using words like "theory" the way anti-evolution nutsos use it.
"The theory of evolution is just a theory ain't it. So is Creationism".
"Theory" has a very precise meaning in science.So does "model".
So, no "specifications" are not "theories". "Design Patterns" are not theories. (God help us all!) .
"Code" is not a "model"
Do some reading first.
@vlad,
Hey you know some incompetent people man :-). An electrical engineer who couldn't explain how transistors work boggles the mind!
But you put your fingure on a subtle point. My point is that even a very competent software eveloper does not *need to know* mathematics (and doesn't even have to complete a course) but one *expects* an engineer to have a thorough grounding in the applied math relating to his discipline.
Of course *Feynman* would find mechanical engineering trivial :-). That doesn't affect the argument.
I've always thought that what really distinguished a real 'engineer' was their association with a 'professional' body. Don't they have to pass exams, pay dues and follow a code of conduct to be classified in any serious engineering discipline?
Of course, I've always guessed that a key reason why software developers are not, and don't ever want to create such a professional society is the desire to avoid being sued. If you're an accredited engineer and you take short-cuts, in most parts of the world I believe that you can be held liable. If you're not living up to some standard, then it is hard to prove that you didn't fulfill your obligations.
On the math side, software development, however far it sometimes drifts, is still a branch of mathematics. While light-weight or medium-weight developers don't need to actively use their math skills often, for more complex code it is a necessity. It all depends on what you are writing.
Paul.
http://theprogrammersparadox.blogspot.com
[quote]What about locomotive engineers?[/quote]
That is why we don't have any in India :P "Engine drivers" used to control locomotives here but they have since been replaced by "Loco Pilots". The job is expected to go to "Track Admirals" within the next decade.
"This is BRILLIANT! I love "logical drafters". MEthinks thou see-eth politics where it is not intended, but it is a VERY interesting concept! I have no argument with "logical drafters". It is a good description of what most sw devs do."
Well, thanks.
I'm continuing the analogy to engineering practice. In a typical engineering firm (e.g. one I briefly worked at where most of the contracts were on the design and delivery of refineries) the engineering team is supplemented by a corps of draftsmen. Ask any draftsman at such a firm and he'll tell you that quite often the "real" engineers (especially the younger ones) miss crucial details that have to be filled in by the more experienced draftsmen.
As a developer I find my work involves higher-order maths from time to time ("proper" projective geometry for camera reconstruction and georectification, and also basic control theory, last year), but not on a day to day basis. I'm not fussed about what people call me, but I do appreciate recognition that what I do requires intelligence and dedication.
Having someone call me a "clerk" with the intent of giving insult isn't something I'd stand for. To me, the term "engineer" makes more sense as when I was studying (I'm a qualified electrical engineer who became a coder) there was a high degree of skills transferability between the various disciplines we all worked on, including the conventional engineering disciplines, coding, software design and mathematics. Someone who was good at one would tend to be good at the others. Where those people ended up in life was a matter of preference.
To put your piece in context, I've read a number of articles linked from prog.reddit recently referring to elitisms like the 80%/20% theory, the idea that a computer science degree must either be hard or pointless, etc. etc. Frankly, like developers, practising engineers from the conventional disciplines are mostly not engaged in "rocket science" on a day to day basis. As coders our work is qualitatively different from theirs, but I don't think the chief differences lie in the difficulty, or in our intelligence.
Overall, I wouldn't have an issue with being referred to as a "logical drafter". My sister is a lawyer who has just started a relatively prestigious job as a legal drafter for the Australian Parliament, where she will be engaged in putting together loophole-free legislation to be tabled in parliamentary sessions. I feel her job will be remarkably similar to mine despite the different roads we've travelled down!
"Having someone call me a "clerk" with the intent of giving insult isn't something I'd stand for."
I can't speak for Reg, but I don't think there was any intent to insult. Unless you think "clerk" == "bad", why should you be insulted when someone says most sw devs are "clerks"? It is description of one mans' perception.
I know I don't have any intent to insult when I say most software developers are not engineers. I have a decade of such "non engineering" experience, the last such at Thoughtworks, which is chock full of brilliant people writing good code.
"As coders our work is qualitatively different from theirs, but I don't think the chief differences lie in the difficulty, or in our intelligence.
Overall, I wouldn't have an issue with being referred to as a "logical drafter"."
I never claimed the former (a difference e in intelligence) and agree with the latter (As a sw dev, I wouldn't mind being referred to as a"logical drafter").
But I do have some thoughts on sw devs and logic. I'll write a blog post on that soon.
Your excerpt from Reg's original post:
"There is a culture of pretending business programming is more than it is. Some of you calling for more Java in University may take false hope that I am on your side. You may think that the people arguing for Scheme, Haskell, and OCaml are elitists. Wrong. They do not have a problem. You are the one with a problem because you don’t want to tell all your friends you have a job as a clerk"
I think it's reasonable to infer from it that we are to consider clerks less respect-worthy than engineers. Having worked as a clerk - transcribing letters, phoning clients and all that administrivia - years ago, as well as a developer, I know which I found more intellectually demanding.
Anyway, your clarification is welcome, I think we broadly agree, and it'll be interesting to see what other comments you come up with.
@anonymous@who wrote last
Just can't comprehend why this was considered an insult. Let me say from an Indian context, I consider myself(a senior developer) nothing more than an IT worker. I work with lot hardware and embedded stuff, but yet unless I make significant design decisions what else should call myself but an IT-Worker. In fact for most Indian software *engineers* are people who work as IT slaves just becuase the pay is higher. When you have surrendered higher thought and advancement , for money made from India-US, Xchange rate arbitrage what is the right word but "IT slave" ? and do you know the pet names IT slaves are given "system Analyst" , "associate consultant" "principal consultant" and so forth. There was joke about the biggest company in India, where a manager did a good oiling job in parking lot during the director's daughter's wedding and he was made a Vice President(parking). So this man carried his title and he could present himself as a vice-president of the company.
The 'engineer' job post looks a bit strange to me. Sure, there is no 'ten years of java' in it, but neither is the assumption that the candidate is capable of just acquiring java.
Namely, this job post asks for a skill set in a different domain, but still asks for a very specific current skill ('must know commercial databases') instead of the capability to evaluate that stuff.
It looks like 'we want someone with five years experience in what we intend to do in the next five years', or, in a nutshell, 'please someone quit at google and come to us'.
@Ravi,
"This is exactly what I said. But applied mathematics is at the core of engineering disciplines. That's not true for software dev. You can have a software developer who doesn't know any maths at all."
What you said was all true. My point originally, which was probably not clear, is that mathematics being at the heart of physical engineering is because of the nature of the physical. However, there are attributes in physical engineering which are the same in conceptual engineering, which may or may not be based in math.
Basically I disagree that mathematics is at the heart of engineering, it is rather at the heart of models and methods of physical engineering.
Ravi,
I work as a research scientist, with a background in math, physics, and biology. Some misc thoughts from my perspective:
Many mathematically capable people are incapable of writing good code, just like many physicists would be incapable of designing a bridge without some serious book larnin' up front.
The notion that some ability with theory automatically makes it possible for you to do something practical is, IMO, "not even wrong".
Building software requires practical skills as well as theoretical skills. And while I have quite a bit of background in math, I use it very little in my research programming; it gives me intuition but it does not inform most lines of code.
So I think focusing on math capabilities is at best a misdirection, at worst completely false.
--titus
@dharh
"mathematics being at the heart of physical engineering is because of the nature of the physical. However, there are attributes in physical engineering which are the same in conceptual engineering, which may or may not be based in math."
Mathematics is bound to the physical? *A lot* of mathematics is about non physical phenomena.
Let's leave that aside for now however.
Give me a few examples of this "conceptual" engineering, please (leaving software aside - whether software development is engineering is after all the root of the debate).
I don't get this division of engineering into "physical" and "conceptual"
To repeat,
So I think focusing on math capabilities is at best a misdirection, at worst completely false.
Unless you're somehow redefining software engineer to exclude most of the people who actually work on and develop large bodies of code, I don't see how you can argue that "If you don't use mathematics in your day to day work, you aren't (an engineer). " If you *are* defining software engineer that way, then I think that it's not a very useful or expected definition.
Or, to get down to the English, is "software" a modifier on "engineer" or is "software engineer" a single term? I consider it the latter. You seem to be saying that it's the former, and that one cannot be an engineer without math, and hence one cannot be a *software* engineer without math. And I disagree with that last statement.
Since you seem to enjoy logic, here's my problem: you claim that math is necessary to engineering. I (and many others) build software without much, if any, recourse to math or mathematical concepts; by your argument, we cannot be software engineers.
Here's another nice counterexample: http://www.kaner.com/. This professor of software engineering is presumably not a software engineer by your definition.
And, just to nail down my point against creative misunderstanding, a definition that disqualifies Cem Kaner from being a software engineer is not a useful definition ;).
This reminds me a little bit of an discussion I saw recently about whether or not "software engineering" is, or should be, part of computer science. I don't know, but it strikes me as a problem if you're *intentionally* graduating computer scientists who don't actually know how to program a computer; it's like graduating mathematicians who don't actually know how to invert a matrix, but know all the theory behind linear algebra. (And yes, I know that there's a big problem with CS departments graduating people who can't program :)
@titus
"Building software requires practical skills as well as theoretical skills."
When did I ever say it didn't? I have always maintained that programming is a distinct skill.
I know many scientists who can't code as well. So I have no conflict with that idea.
As you correctly note, building (good) software requires both theoretical and practical skills.
If you intend to do research in the sciences, you also need math skills.
So you differ with what exactly?
"The notion that some ability with theory automatically makes it possible for you to do something practical is, IMO, "not even wrong".
Since I never made a claim like this, you seem to be setting up a strawman and then knocking it down? :-)
What I *am* claiming is,to be a good programmer you need to know both the theoretical and practical aspects of programming. This is consonant with the the first sentence of this comment, which is a quote from your comment.
To be a researcher or a scientist or an engineer, you need a good grasp of mathematics, irrespective of whether you program or not.
*That* is my claim. I would really appreciate it if you react to what I did say than what you think I say :-)
"""
To be a researcher or a scientist or an engineer, you need a good grasp
of mathematics, irrespective of whether you program or not.
"""
Only if you define researcher and scientist fairly narrowly, which seems to be your game. I know plenty of (for example) quite successful biologists who would find it impossible to solve a quadratic equation.
They have analytical skills in spades, though. Maybe that's what you actually intended? It's certainly a more useful distinction IMO; I don't know anyone who is a successful scientist, researcher, or engineer who doesn't have good analytical skills.
@Titus,
"Unless you're somehow redefining software engineer to exclude most of the people who actually work on and develop large bodies of code,"
But that *is* what I am doing. I am stating as an axiom (or premsie) that there is no engineering without applied math.
I do so explicitly in my blog post claim that "software engineer" is a deceptive title. Building large bodies of code does not make you an engineer, just as building a 100 chairs, no matter how useful, does not make a carpenter an engineer or carving a statue, no matter how beautiful makes a sculptor an engineer.
Unless your work is based on applying mathematics/science to create an effect in the real world, you are not an engineer.
That goes for professors too. ;-)
And since I dispute the validity of "software engineering" when the word is applied to people who don't understand or use mathematics, showing me links to people who call themselves (or who other people call ) "software engineers" doesn't advance the argument.
"Your game"
There is no "game" here. This is just a blog. I made some premises and extrapolated from there.
You can certainly challenge the premises or the deductions, but you can't put words in my mouth
"They have analytical skills in spades, though."
Well, Sherlock Holmes had analytical skills. That didn't make him an engineer. :-D. Many philosophers play word games with logic. That doesn't make them engineers either.
What exactly do you mean by "analytical skill" (that goes against my thesis that engineering has a core of math)?
Another friend of mine, who is a very talented programmer (he recently moved away from enterprise app development) , when asked why he changed the focus of his career, told me,(paraphrased) "Humanity has only a very limited amount of talented people. It is a crime against humanity to employ that talent to bug fix enterprise applications or futz around with Ruby On Rails deployment issues. I want to do something meaningful". (As you can see I have interesting friends :-) ).
Well said :)
Hey - fun! Let's just make up a definition, and then write a blog entry that draws conclusions based on the definition we invented!
As per Webster's dictionary:
engineering:
...
2 a: the application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to people b: the design and manufacture of complex products
Hmmmm .... so let's see.
Although definition a) is obviously targeted towards the physical sciences, and so not totally relevant here, it's important to note that it explicitly says "science and mathematics". Since clearly there's a significant amount of science and mathematics used when developing software (and yes, logic and things like graph theory, set theory, many/most algorithms, etc. still fall under mathematics), there's a strong implication here that it's an engineering discipline.
And as for b) hmmmm .... design and manufacture of complex products. Sounds like software development fits in there just fine.
You can make up whatever arbitrary criteria you like about what you think an engineer is. ("You're only an engineer if you wear glasses".) Doesn't mean the rest of the world agrees with you - or that what you're saying makes sense!
@darose,
Hey Fun,
Let us look at the dictionary, reject or attenuate definitions that go against our preconceived positions and write a frivolous comment on someone else's blog and consider ourselves clever.
Listen idiot, my whole *point* was that people who *don't* explicitly use logic and maths in their day to day work are not engineers.
I didn't say software developers *couldn't* be engineers, only that many aren't. *Read* the blog entry before spouting off.
All thinking != logic. (again , read the followups , linked to from the post, for use of formal logic).
When was the last time you saw a j2ee developer work out a complex logical proof? (use of logic) or develop a complex algorithm (using algorithmics)??
In your second definition ("design and manufacture of complex products", "design" and "manufacture" have very specific meanings rooted in the post Industrial Revolution world.
e.g All thinking is not design. All creation manufacturing. A musician can "design"
and "manufacture" a complex sonata. That doesn't make him an engineer.
Listen to Dr Lauffenberger's speech (linked to in a follow up blog entry, which in turn is linked to in the beginning paragraph of this entry) ) before you decide to expose your ignorance in an ill constructed argument.
In other words, the dictionary is right. You are not. The "world" (as expressed by the dictionary)and I are in consonance. *You* didn't get it. Try again.
Next time, *read* the actual blog entry (vs listening to voices in your head) and *do some thinking* before commenting here.
Thanks in advance.
(The world has an unending supply of idiots apparently, sigh)
Post a Comment