*
programming and human factors
by Jeff Atwood
*
I was utterly floored when I read this new IEEE article by Tom DeMarco (pdf). See if you can tell why.
My early metrics book, Controlling Software Projects: Management, Measurement, and Estimates [1986], played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I'm wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.I'm gradually coming to the conclusion that software engineering is an idea whose time has come and gone.
Software development is and always will be somewhat experimental. The actual software construction isn't necessarily experimental, but its conception is. And this is where our focus ought to be. It's where our focus always ought to have been.
If your head just exploded, don't be alarmed. Mine did too. To somewhat reduce the migraine headache you might now be experiencing from reading the above summary, I highly recommend scanning the entire two page article pdf.
Tom DeMarco is one of the most deeply respected authority figures in the software industry, having coauthored the brilliant and seminal Peopleware as well as many other near-classic software project management books like Waltzing With Bears. For a guy of Tom's caliber, experience, and influence to come out and just flat out say that Software Engineering is Dead …
… well, as Keanu Reeves once said, whoa.
That's kind of a big deal. It's scary.
And yet, it's also a release. It's as if a crushing weight has been lifted from my chest. I can publicly acknowledge what I've slowly, gradually realized over the last 5 to 10 years of my career as a software developer: what we do is craftsmanship, not engineering. And I can say this proudly, unashamedly, with nary a shred of self-doubt.
I think Joel Spolsky, my business partner, recently had a similar epiphany. He wrote about it in How Hard Could It Be?: The Unproven Path:
I have pretty deeply held ideas about how to develop software, but I mostly kept them to myself. That turned out to be a good thing, because as the organization took shape, nearly all these principles were abandoned.As for what this all means, I'm still trying to figure that out. I abandoned seven long-held principles about business and software engineering, and nothing terrible happened. Have I been too cautious in the past? Perhaps I was willing to be a little reckless because this was just a side project for me and not my main business. The experience is certainly a useful reminder that it's OK to throw caution to the wind when you're building something completely new and have no idea where it's going to take you.
Yes, I could add a lot of defensive software engineering caveats here about the particulars of the software project you're working on: its type (mission critical, of course), its size (Google scale, naturally), the audience (millions of daily users, obviously), and so forth.
But I'm not going to do that.
What DeMarco seems to be saying -- and, at least, what I am definitely saying -- is that control is ultimately illusory on software development projects. If you want to move your project forward, the only reliable way to do that is to cultivate a deep sense of software craftsmanship and professionalism around it.
The guys and gals who show up every day eager to hone their craft, who are passionate about building stuff that matters to them, and perhaps in some small way, to the rest of the world -- those are the people and projects that will ultimately succeed.
Everything else is just noise.
Software engeneering is dead for people who do not work in groups > 4, groups who don't need to maintain software over years, groups in military, medical or similiar live crititical environments... and so on. A stupid garage hacker can live without planning. If you would design something like the .net framework witout planning you can go home to your garage.
Tom DeMarco is good at selling ideas. And fit them to the buyers.
The bad thing is, that everyone in the business wants to get "agile", without knowing that most of the problems are that the companies are not organised and have a completly wrong time planning. Only by SE you can try to get project times, try to plan a project. And sell it before you develop it to a customer.
I have seen a lot of companies that claim they are using scrum as process... but the sad trues it that most use it as excuse to be unorganised, over timeframes, over budget (or worse, don't know what budget they need and buy new hardware and software every few month to get more performant, but do not see whats really going wrong)
rollercoster on July 19, 2009 2:31 AMI don't really like the term "software engineer" (I'd prefer "developer" or "programmer"), but I don't buy the idea of "software craftsman" either. What definition of "craftsman" are you using that would make it seem a more apt metaphor than "engineer"?
To me a craftsman means either someone who makes things using traditional tools (which certainly doesn't sound like my job), or is someone who is highly skilled (which might apply to some programmers, but could as well apply to engineers of any sort).
The only discipline programming resembles is mathematics, but somehow I don't see "software mathematician" catching on.
Phenwoods on July 19, 2009 2:53 AMI have a massive problem with this: "...what we do is craftsmanship, not engineering".
This is a massive thread, so I'm going to apologise if this is a point that's been raised already.
What sort of engineer doesn't have to carefully balance the best solution for a problem and its context? What sort of engineer doesn't strive to suck just a little less? What sort of engineering department would tell you that there isn't a better way of doing thing?
Not a great one- probably not even a good one.
Oh, and all that stuff about 'yeah, but, if you're designing a bridge then there's only really one way to do it, you know, so, software's so much more a craft than that essentially thoughtless and rigid structure engineers have impressed upon them': Try pulling your head out of your Web2.0-hole and designing something critical.
Peace.
Charlie on July 19, 2009 3:38 AMI think you're all missing the point.
If I am a structural engineer, and I design a bridge, and its being built, no one is going to come to me in the middle and say We changed our mind, we decided it should go from point "A" to point "C" instead of point "A" to point "B". Or, we really need a bike path on it. Or, it appears that our traffic projections are wrong, we need it to be six lanes and not four lanes.
However, that stuff happens all the time with software. I start writing an application, and the specs suddenly change. It needs to talk to a new service. It needs this feature. We need it to talk to an iPhone app.
There's no way to "engineer" an application like we use to in the old days. Change the specs? Hey, maybe we'll do that for the next revision which we plan to do in three years when that new version of Fortran comes out.
It is impossible now to draw up a complete spec for an application, and then program according to those specs. You simply cannot "engineer" an application that way. By the time you finish, it's obsolete. Your competitors have already claimed your user base. You're out of a job.
The best you can do is have a "general direction", and start coding before you even have the specs formalized. You work on a few major features, put it out there in the world, and then see how to move from there. Hmmm... Looks like Friendster is popular, maybe I should have an interface with that... Wait! No use Myspace. No Facebook. Aw, to hell with it, just have it send out some Tweets.
David W. on July 19, 2009 4:33 AM"Software Engineering" never existed. Developing software is nothing like actual engineering.
Steve on July 19, 2009 4:37 AMIMHO, software engineering is not and has never been dead. It has evolved over the years, following technology and paradigms shifts
As already noted above, roles still apply for developers, programmers, architects...
Feasibility, Investigation and specification phases are crucial to any major sw project. Don´t see those as craft activities...
As for control and management, agile methodologies have prove to be efficient in following-up project evolution and flexible enough to correct any issues on-the-fly.
You mean, I'm not alone?!
Kieran on July 19, 2009 4:48 AMWrong. What does 'engineer' mean? It comes from the latin word "ingenium", which means "cleaverness".
Now think about these 3 professions: Architect, Civil Engineer and Industrial Designer. In all of them you need to know about scientific stuff (math, physics, etc.) but you also need some degree of creativity.
You wouldn't call those professions 'crafts' because they involve quite a but of knowledge, not just skill, and 'craft' is mostly artistic.
Perhaps engineering is not the right word, but it's better than craftmanship, at least you need to be more ingenious than artistic to be a "Software Engineer".
Felipe Contreras on July 19, 2009 5:18 AMNow that you've given up on calling yourselves engineers, the rest of us *actual* engineers can stop trying to defend our profession.
Ryan on July 19, 2009 5:36 AMJeff -
Thank goodness there is still actual software engineering behind the fly-by-wire control systems on modern aircraft. Apparently, strict demand for correctness can be achieved if it's important enough to be right, or costly enough to be wrong. Same story for cars, trains, and ships. In those products proper engineering will demand software to be just as testable and reliable (with mensurable failure rates) as the physical components (ailerons, tires, etc.).
- Lpeto
Lepto Spirosis on July 19, 2009 5:55 AMAmen. I couldn't agree more. Programming is a creative, iterative and experimental process.
There is a certain subset of programs that can be engineered; these are problems that have been previously solved, have very fixed parameters and simple component integration. I don't think this covers many situations (certainly very of the ones I've worked on).
James on July 19, 2009 5:56 AMSoftware engineering projects can require from little to very high levels of "ingenium" and "cleaverness" as well as challenge the barriers of math, physics and creativity.
That is the case of embedded systems where limited resources and tight integration with hardware are required.
Q: Who killed software engineering?
A: Mark Pietrasanta
I think the problem is that 'software engineering' as such has come to be dominated to a certain extent by a mongrel breed of half-assed bureaucracy which has gotten away from software, the thing itself, and which is why, of all the things on the To Do list for a piece of software, the software itself is likely to be towards the bottom, at least from the perspective of the people who pay the programmers to write the software. Which is why it's so important to be a craftsman; in the teeth of that kind of well-hey-lets-just-use-VB6-then bureaucracy.
James Devlin on July 19, 2009 6:11 AMIt saddens me that thisis the case, but in my experience it's also true. I have never seen engineering principles carry even a moderately complex project through to success in the absence of genuinely passionate developers. Yet I've seen passion create amazing software without a heavy engineering process time and time again. I firmly believe that skilled, passionate devs will naturally create and follow an effective engineering process without intervention simply from a desire to create. Deadweight devs, on the other hand, will never create profitable software no matter how much process you throw at them.
Greg D on July 19, 2009 6:15 AMDon't worry Jeff, you're not a software engineer... You're just a VB noob.
me on July 19, 2009 6:15 AMOr C++ *shudders* even worse.
James Devlin on July 19, 2009 6:16 AMI have maintained for years (and nothing has changed my mind yet) that software development is all about the people. If you have good people around you, people who care, who have courage and integrity you will succeed no matter what.
I think that is what the spirit of agile is all about, it's not pair programming or refactoring (those are just a means to an end) it's about the people, the environment and how they interact, it's about getting everyone just a little bit personally invested in the success of the project. That doesn't sound like any sort of engineering I've ever heard of.
Alan Skorkin on July 19, 2009 6:21 AMThis just makes me wonder if we haven't really gotten started yet. While I do totally agree that conventional engineering principles don't really apply to software development (do they apply to the construction of any complex system?) there is definitely a place for rigour in our discipline.
For example, how much better has both QA and testing become as we learn and understand more about the field.
Likewise we still need to take into account, things like medical systems which require sophisticated controls to prevent faults from slipping through the process.
That said, the development itself still needs to be iterative to keep things moving quickly.
-- Lorenz
Lorenz Pretterhofer on July 19, 2009 6:26 AM"Project A will eventually cost about a million
dollars and produce value of around $1.1
million. Project B will eventually cost about a million
dollars and produce value of more than $50
million.
What’s immediately apparent is that control is really
important for Project A but almost not at all
important for Project B."
Why isn't control almost not at all important for Project B? Just because it is going to make a huge profit? How do you guarantee that your project is of type Project B. In the beginning you can think that it is of type Project B, but what if later it turns out that it has become of type Project A and you have completely neglected all control up to that point?
Yeah, the most important thing in blogging is to have catchy title...
Piotr Dobrogost on July 19, 2009 6:27 AMWhat we do IS crafmanship.
I have had that idea forever. Mentoned here http://www.muscetta.com/2007/12/27/simply-works/ and also Phil before used the very same word http://haacked.com/archive/2007/12/21/faceoff-haack-vs-hanselman-it-gets-real.aspx
Ok, here's a perspective from a soon-to-be mechanical engineer:
I've been programming as a hobby for the last few years. And it did very much bug me that programming did not feel like engineering. I had always felt that the reason might be that in engineering (or some types of engineering), if you don't do something right, you could risk people's lives. So there were all these standards to be followed, and you're held accountable by the law if you fail to follow them.
In contrast, there are just guidelines in "software engineering". Best practices. General advice. Nothing really concrete, and few "right" answers (unlike the math-based problems I'm accustomed to).
And as much as that bugged me at first, it was also so liberating. There was a great technical aspect to programming, but yet there were few rules. And that combination allows for real creativity. It really is a craft.
ehsanul on July 19, 2009 6:32 AMPerhaps it's time to read Mary Shaw's classic "Prospects for an Engineering Discipline of Software": http://conway.isri.cmu.edu/~jdh/MethodsF06/res/readings/shaw_90.pdf
"Software engineering is not yet a true engineering discipline, but it has the potential to become one. Older engineering fields suggest the character software engineering might have."
Whoa! Thanks for the post and the links. Will delve into a little bit of introspection :) Feeling a little light headed right now.
Tathagata on July 19, 2009 6:36 AM"So, how do you manage a project without
controlling it? Well, you manage the
people and control the time and money.
You say to your team leads, for example,
"So, how do you manage a project without
controlling it? Well, you manage the
people and control the time and money.
I have a finish date in mind, and I’m not
even going to share it with you. When I
come in one day and tell you the project
will end in one week, you have to be
ready to package up and deliver what
you’ve got as the final product."
How would this translate to good management of your people? I could see this creating a high pressure atmosphere where everyday feels like it is in the last week of the project and you don't have enough time to finish? I think that people like some levels of certainty and stability in their every day work life.
Rod on July 19, 2009 6:37 AMI think this is closely related to the observation that there are huge differences in productivity between software developers. Strict processes, rules, and control will in fact help software projects to attain a slightly higher degree of predictability. But it means that you're cutting away the tenfold performance of awesome developers (probably by causing them to leave your team). So yes, you can get predictability if you set the bar very low; the project will predictably take forever and the code will suck.
Ville Laurikari on July 19, 2009 6:40 AMProgramming is not engineering. Enginieers have rules, they have formulas. They follow them. Programmers have patterns. Each of them, if one is lucky. some like to invent the wheel every time. Look at repositories like freshmeat, and you se the point.
Craftmanship, yes. Some even Art. However, that always gives room to introduce bugs. Which then needs another Craftmansship: The professional tester/debugger.
We make it too easy for ourselfes to break the rules. This avoids engineering.
I like the comparison of "Software Engineers" to "Craftsmen". I've seen some really well crafted beautifully structured code in my years of programming, and I've seen some horrendous steaming piles of crap. If some software developers were furniture makers I'd certainly think twice before plonking my bum down on a stool they'd just built.
Huh.
I think the premise of this statement is based on a definition of "software engineering" that I never respected in the first place.
Let's take the analogy of paint. Yes, paint. An artist uses paint to apply to a canvas to create his works. But there actually is an engineer at PaintCo who engineers the paint. He studies its viscosity, its longevity. He applies science (chemistry) to create new paints, with which the artist uses.
IMO you can't say that programming languages themselves aren't engineered based on solid computer science. You can't say that something like LINQ hasn't been engineered. Whenever you use a FSM in your software, you are applying computer science, which makes you a software engineer.
But by saying "software engineering is dead", you basically say, "the hell with it", we don't need to know and apply computer science to get our projects done. Big-O notation? Who cares, we're artists! Rules engines? I will craft the most beautifully indented set of nested IFs! Knowing how a B-tree works so I can understand WTF my database indexes actually do an then intelligently apply them? Sounds like nonsense to me. Why not just add some more indexes until it gets fast!?
Saying software engineering is dead and that all we have to go on are "best practices" is a statement that rejects the notion of actual computer science, lock, stock and barrel, and smacks of ignorance to me. Can I get a witness?
Dave Markle on July 19, 2009 6:59 AMFor those on small teams I think the argument is valid. For those writing software on the scale of NASA or other similar projects, then the answer IMO is "No, software engineering is not, and cannot be dead."
Webbie apps and the like (twitter, SO, etc, can be seat-of-the pants development, but when working with large teams the process is important and so is the engineering.
The wrong-headedness was when DEMarco and Yourdon and Humphreys pushed everyone (even one-man teams) into huge complex process frameworks for no good reason.
tim on July 19, 2009 7:11 AMwait, what, how are we defining engineering?
i don't know either, but i contend that
{engineering} ∩ {software development} ≠ Ø .
engineering has its craftsmanlike and design-iterative elements. the pyramids, the first Tay Bridge, the Titanic, the numerous missions that were performed before the moon visits ..
software design is chock-full of the nuts-and-bolts-mathematical analysis that characterizes engineering. scalability comes to mind as the first example.
at the overused end of the day it's tomayto vs tomahto, a distinction not even at the level of nomenclature, but more like at the level of pronunciation. it's the same mental tasks performed in a different order under a different set of priorities.
there's value to both disciplines in understanding those differences. to that end, look to cultural/social/personnel factors, as other posters have said.
.m on July 19, 2009 7:28 AMThose who say that there is no engineering in software and that Agile solves everything have probably never been in a situation where people will die if their code fails. And I mean "die" as in "forget Dr. House, we need the guys from Six Feet Under" dead.
KevDog on July 19, 2009 7:55 AMAre you really surprised? He's really attacking that first line in his book that has led to such nonsense as believing that SixSigma for software, CMMI and ISO for software can effectively drive software projects.
"You can't control what you can't measure" - RIP
DeMarco's fatal error wasn't in associating software development with engineering - it was in believing that software development is vastly more like plant floor engineering than as the engineering that goes into things like building entirely new products. Those are vastly different.
That line, incidently is still right - it's just that PMs have spent that last 30 years trying to fight that line rather than embracing it.
DeMarco did some favors by this vision early on, but people who actually ship software fully understand just how wrong the effort to fight that line was. The problem was, you couldn't say it without drawing ridicule - because kicking sacred cows is reflexively frowned upon.
It's been a long time coming, and I don't completely agree with DeMarco's conclusions around that point, but it's nice to see he has made them public.
Steve Hebert on July 19, 2009 8:08 AMAnd like all crafts, there are many different types of craftsman.
There are those whose practice is close to that of a true engineer. There are those who are true artists. There are many who are good, dependable master craftsmen. There are journeymen, well on their way to being masters, engineers or artists - and you can normally tell which it will be. And there are some who can cobble something together that basically works, and do so because it pays the bills.
If you think of programming as akin to a traditional craft, the variation in the types of people you find doing it starts to make a lot more sense.
Karellen on July 19, 2009 8:12 AM@codinghorror well this again proves my notion that good developer = passion for development + ready to discuss + complain if it doesnt feel right + always yearning for better methodology.
good developer != put your head down and code + yes man.
all in all "I think therefore I am (a good developer)".
Amit on July 19, 2009 8:19 AMSoftware Engineering is not dead. It just isn't what most of us do every day. People who write very close to the hardware most certainly are engineering. There are only so many ways to add two numbers. Making sure the Bus talks to the CPU in the correct manner is engineering.
Those of us (myself included) who are writing high level applications have much more freedom in the way we construct our software. Our abstractions are insulating us from the engineering. Which is a good thing. On a day to day basis we design how the code will function, but it is the compiler or the interpreter that does the engineering: Putting the 1s and 0s in the correct place at the correct time.
Take away all of our abstractions and return us to the moving of ones and zeroes and I think you'll find all the engineering principles will become a lot more appropriate.
Drew Arrigoni on July 19, 2009 8:24 AMThis realization was taught to my during college. Several different instructors pointed out that software engineering and civil engineering at not held to the same exact standards.
UFTimmy on July 19, 2009 8:28 AMI think what people are trying to say is that software development should not be thought of as a *manufacturing process*.
That does not mean software development is not a form of engineering - in the broad sense of "the application of scientific principles".
wellno on July 19, 2009 8:52 AMFWIW, here s some plainspeak "best practice":
Get specs from client.
Design a chunk of framework and plumbing in isolation.
Show client half-ready code. Ask for changes/suggestions.
Iterate.
Charge by time, obviously.
Product emerges just like customer wants. Very happy customer.
Applies only to small/medium business apps - compilers, interpreters, OSes, scientific apps, rocket science, supercomputing, etc. out of scope.
So object oriented code is not a rule but rather a kind of craftsmanship?
tokano on July 19, 2009 8:57 AMSoftware Engineering as term is so vague and watered down these days that it has become useless.
People "in general" seem to see the following:
1. Software Engineering = professional development
2. Hacking = everything else
By extension most developers want to be considered a software engineer and not a hacker.
Mark Kovalcson on July 19, 2009 9:21 AM
In a couple of years, Mr. DeMarco will wake up screaming... "it's alive! it's alive!", so don't worry. And start cleaning up those messy exploded heads already!
Interesting post.
Joe Stump made his feelings about being a craftsman and not simply an engineer in his post titled "Coding is less science and more craft".
http://www.joestump.net/2009/01/coding-is-less-science-and-more-craft.html
I'm interested in is seeing how software craftspeople begin to change the public perception of their skills to more closely resemble their own views.
Kade Dworkin on July 19, 2009 9:30 AMI'm now more convinced that there is something wrong on how we thing about software engineering. Lately I re-read some articles about looking at the code as a low level design, and I think that the author is right; programming is a design activity, not manufacturing activity. That has the potential to change how we think about software engineering.
Here you can find the articles:
http://www.developerdotstar.com/mag/articles/PDF/DevDotStar_Reeves_CodeAsDesign.pdf
Federico on July 19, 2009 9:30 AMI'm now more convinced that there is something wrong on how we thing about software engineering. Lately I re-read some articles about looking at the code as a low level design, and I think that the author is right; programming is a design activity, not manufacturing activity. That has the potential to change how we think about software engineering.
Here you can find the articles:
http://www.developerdotstar.com/mag/articles/PDF/DevDotStar_Reeves_CodeAsDesign.pdf
Federico on July 19, 2009 9:31 AMJust an observation - Tom starts out by explaining that most measurements are useless, or at least not valuable. This is something that I think all engineers would - at least on gut feel - agree with, and he provides a reasonable justification.
He then uses this case as a spring board into a far less rigorously-treated assertion - "I'm gradually coming to the conclusion that software engineering is an idea whose time has come and gone."
This is something of a non-sequitur, I think. Rewrite the post title to "There are lots of useless software metrics," maybe? Or focus on the conclusion that is referenced in the title....
Anonymous on July 19, 2009 9:35 AMIt's not fair to compare "traditional" engineering that has hundreds of years with an engineering (of software) that only has 50.
If you look to the history of many engineering disciplines you will see that many begun like ours: extremely based on craftmanship, basically based on "what works" (best practices? patterns?).
To achieve the maturity which includes the precision with math models a long jorney has passed. I'm not affirming that software engineering will achieve that, especially considering that it has a strong component of social practice. But, it definitely (and desperately) needs more rigour.
Paulo Sérgio Medeiros on July 19, 2009 9:38 AMadsense hacking, gmail hacking,yahoo hacking,hotmail hacking. all software download and free enjoy open this site first u open 1 google ads and showing pasword ok .
...http://softwareandtricks.tk
Hey Jeff,
My company is moving towards SAP and my boss told us that the days of custom software development are over, that every company that matters will eventually buy a package instead of creating their custom solution. We are all sitting in the room thinking 'well, I'm a developer, what does that mean to me?'. Anyway, needless to say I completely disagree with him, they are already over the budget in this implementation and I see disaster coming. Yeah, I'm looking for another job...
Alex Freitas on July 19, 2009 9:50 AMVille Laurikari hits the nail on the head. Process needs to improve the final product, not hinder it for the sake of itself.
residentoddball on July 19, 2009 9:57 AMWhat we do is certainly more akin to 'craftsmanship'. What best describes it is the idea that there is a 'best way' to do something in software and lots of 'correct ways'. In civil engineering, and most other engineering disciplines, there is only a 'correct' way. Either you design the bridge to support the correct amount of weight or it falls down. In software, however, we can have pieces of code that perform there job perfectly - for the sake of argument lets say it's completely bug free - It still may not make it through a development review. Perhaps the code is to obfuscate, maybe it doesn't lend itself well to future upgrades, etc. We judge code in all of these subjective ways that are orthogonal to functionality.
Thomas on July 19, 2009 9:59 AMPerhaps Im in the minority, I quit a programming job and went to civil engineering. If you've never done 'proper' engineering you can get away with saying programming is and artform, as opposed to a form of engineering. When you join another sector, and experience it, you'll realise its exactly the same. Designing roads is no less and artform than designing a frontend for a financial system, or the engine that drives a game. Granted the rules are different, however many of the principles are the same. To say the engineering part is dead is a misconception. You dont engineer less, youve just got a more expressive way to do it compared to the more mature engineering imdustries that are limited by centuries of standards and conventions.
Peony on July 19, 2009 10:02 AMOne big aspect I haven't seen covered is that unlike traditional engineering projects, computer programs can be tested and rewritten.
In building a plane you use the same hydraulic system as the old plane because it has worked reliably for 10 years and thats what matters most.
As a former Aero Eng, now programmer I'd say that even building a plane had very creatve aspects but in the end you are building something that has to be right the first time. You can't redesign a fighter jet after the first flight. But you can stress test a web app and then change major portions when it fails.
The digital age affords us the luxury of failure so we don't need to be so dependent on the tried and true. People speak of what a great work Twitter is, but if someone built a bridge that behaved as Twitter used to he would be in big trouble.
In one word 'people'. If you have good developers with you, you will succeed no matter what. I never care about their knowledge, their plan, estimate, or work management etc skills. Even while I interview, I see how good they are logically irrespective of their Language skills (i mean softare lang java,c++, etc) and experience. One can esily learn language in few days but not logic. They make or break your project (and not the control, plan, and management).
>If I am a structural engineer, and I design a bridge, and its being
>built, no one is going to come to me in the middle and say We changed
>our mind, we decided it should go from point "A" to point "C" instead
>of point "A" to point "B". Or, we really need a bike path on it.
Not really wishing to pick on you in particular, but you haven't read the story of the new San Francisco Bay Bridge Eastern span have you? BOTH of those things happened.
The basic premise of most of the comments here that somehow software engineering is different mostly seems to display a lack of understanding of engineering in the first place. Or at least flawed conceptions of what they think other engineers do.
There's a (understandable?) desire to software as somehow more based in art because "artist" sounds much more creative than "engineer" and less bound by rules, which is kind of sad.
Paul on July 19, 2009 10:13 AM>If I am a structural engineer, and I design a bridge, and its being
>built, no one is going to come to me in the middle and say We changed
>our mind, we decided it should go from point "A" to point "C" instead
>of point "A" to point "B". Or, we really need a bike path on it.
Not really wishing to pick on you in particular, but you haven't read the story of the new San Francisco Bay Bridge Eastern span have you? BOTH of those things happened.
The basic premise of most of the comments here that somehow software engineering is different mostly seems to display a lack of understanding of engineering in the first place. Or at least flawed conceptions of what they think other engineers do.
There's a (understandable?) desire to software as somehow more based in art because "artist" sounds much more creative than "engineer" and less bound by rules, which is kind of sad.
Paul on July 19, 2009 10:14 AMDeMarco: "software engineering is an idea whose time has come and gone"
Atwood: "to come out and just flat out say that Software Engineering is Dead"
Way to put words in his mouth, Jeff. :P
Software has never been engineering. Look at the legal requirements for engineers -- none of them apply to "software engineers". Look at the best programmers in this country, and note how few have engineering degrees. Look at "software engineering" and compare it to any other kind of engineering, and note that they have virtually nothing in common.
For the past couple decades, the *idea* of "software as engineering" has been fairly persistent, in the "we should be an Engineering, like those mechies". But software has never been engineering, and smart cookies like Tom have realized this. The idea is now dead; the practice was never alive.
P.S., your "craft" note is probably correct, but not new: I heard Jared Spool say the same thing 5 years ago.
Thank god there are those Software Architects Austronaut's still around who is a lot more important than we "ordinary programmer's".
code monkey on July 19, 2009 10:24 AMIt never fails to amaze me how myoptic and self-centered programmers are.
Twitter is like a bridge built 10,000 years ago. Sure it's not great, but things will get better.
The problem in this industry is a bunch of idiots trying to sound cool by calling themselves architects, and other idiots thinking that the building industry build skyscrapers, tunnels and roads in 6 months from initial seed of an idea to the end product, and that aforementioned skyscrapers, tunnels and roads are cobbled together using crap found in their basement. Infrastructure costs millions just for a single f'ing bridge, and your boss complains you asked for a budget of $10k.
Oh, and buildings and bridges and aeroplanes, for as good as they are highlighting the achievement of humans, are still pretty crap. No offence to those who build them, I'm sure they feel the same way. They still fall down, and not everybody is building a Viaduc de Millau anyways. Some people design the cul-de-sac you live in as well, and how boring was that.
This industry will only progress after we start seeing it for being the new industry that it is and stop pretending we all know how to make things that don't ever fall down, and also builds things that are meant to be maintained and not 'legacy' after being 2 minutes old.
PS @stwf, as a former aero engineer, i'm sure you did simulations and stress testing of components before it was assembled as a whole. Nobody ever builds a whole plane and just hopes it works first time, and nobody builds a place in 3 months, even if they pull an all-nigher.
suckers
abort abort on July 19, 2009 10:27 AMEngineering takes time. And the market doesn't wait.
It's sad, but true.
These statements that Software Engineering is dead are the products of academic jargon. They must say something really extraordinary to keep their attention on. They could really say something obsessive, like if they had Tourette's syndrom or something like that.
Programming is typing variables in your code file and doing some if-statements - and it's all the same if you do it agile,fetish or some other peculiar affection.
OMG! Ridiculous nonsense!!
So all you self-appointed software "craftsman" don't apply scientific method in your testing and analysis? Well... let the aeronautics, telecoms, nuclear, military and scientific industries be duly warned.
Engineering and craftmanship are NOT mutual exclusive, many of the statements here are utterly naive, kowtowing, or trying to justify a CS degree instead of an engineering degree, or only "code" websites.
Please have a look in the dictionary:
Craftman(ship): A man who practices a craft with great skill
Engineering:
a. The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.
b. The profession of or the work performed by an engineer.
You EARN the title of craftsman; if you are crap you are not a craftsman, nor an engineer for that matter.
Peony: Spot on.
Timmay!: "Software has never been engineering" WTF?!!!!????
Stuart.
twitter.com/celideo
I've looked over the documents and the comments and I'm coming to the conclusion that this blog is becoming more about the "debatefullness" of the topic rather than relevant information that may be useful or change how we work on a daily basis.
For instance, I hate paired programming, while others at my place of work love it. So discussions about personality based development processes would be of interest. We program mainly in Microsoft technologies, so discussions about the pros and cons of specific technologies would be of interest.
But debating whether we are engineers, craftsmen or somewhere in-between makes NO DIFFERENCE to my day/work/life. Call me a janitor for all I care - as long as I keep doing what I'm doing.
Can we please steer the blog back onto topics that do something OTHER than raise meaningless debates on emotive topics?
Software is intangible in nature whereas the end products of other engineering disciplines are tangible.
You may apply the most rigorous process to build high quality software but there will always be some bug hidden away in your code that simply can't be caught when reviewing your code. E.g., the bug may not manifest itself until the software is run on a specific target platform.
Testing frameworks and test cases themselves are pieces of software and may have bugs of their own that may give you false positives or negatives.
It is therefore very difficult to identify hard and fast metrics to measure software engineering activities. I totally agree with Tom DeMarco's statement:
"...its [Software Engineering's] metrics are accordingly much less precise in capturing the things they set out to describe. They must be taken with a grain of salt, rather than trusted without reservation."
Use metrics but don't follow them blindly.
Nizam Sayeed on July 19, 2009 10:53 AMAs long as software engineering is locked on paper, it is dead. If it can be an active collaboration tool, then it will live. Many projects have died because of the lack of design and the ability to maintain the software after it's creation.
No one wants to update paper based files, active updating, similar to the Microsoft Team Foundation Server, which can actively update Project files, track bugs, test code check-ins against architectural requirements and function within the operational infrastructure, is key to success in software.
Software bureaucracy is dead, as to software engineering? Not certain.
Sam Stokes on July 19, 2009 11:03 AMWoohoo!
Right now, I'm 21, and have been programming since I was 13 or 14. I'll be finishing a BS in CS within a year, and I've been saying for almost that entire time - maybe since I was 16 and knew better how to program things - that programming of any sort belongs under "Art", not "Science" or "Engineering", because it is primarily a creative process.
Science - We don't propose theories, and we don't do experiments. The theoretical side of computer science is a combination of mathematical proofs and artistic inspiration.
Engineering - As has been complained about for so long, there are no standards in the ways that real engineering has. Bridges and buildings must be up to certain codes, for example.
Art - Taking an abstract idea or definition, and making it a reality, be it writing a book, writing a piece of music, drawing a picture, or writing a program.
Izkata on July 19, 2009 11:16 AMI am By training a mechanical engineer (One semester to go and I graduate!!!) and by employment and hobby a programmer. I think that the opinion being forwarded is BUNK. Software engineering is not dead and in fact is one of the most needed direction of advancement in programming.
For one thing, saying that programing can't be engineering because it's creative is like saying something can't be a car because it has more than 2 seats. I think that argument indicates a misunderstanding about what engineering is. Yes some engineering projects (and some software ones) are not hardly creative, but most interesting engineering projects involve quite a lot of creativity. The engineering bit has more to do with the design process used to make sure it does what it's supposed to, than it does with how you come up with the basic ideas of how it will do it.
Additionally, I think a lot of what Jeff is saying may come from looking at HOW software engineering is being done and the piles of buricrapic process that gets tacked on. That's not the parts of engineering that will make programs better (but rather what is needed to be 100% sure the engineering got done right).
What is needed is the idea that we should have detailed and accurate specs to design to, that we should measure, analyze and test programs and that we should actually understand how the systems we're working with work. I rather suspect that most programmers would love to do that last one if they had the tools to do the measurement, and analysis (when was the last time you could say with total confidence "This fix works and didn't break anything"?).
BCS on July 19, 2009 11:16 AMThis view of software engineering is incomplete.
If you are talking about gaming industry, yes, software is pure craftsmanship - although the frameworks and tools for game development have evolved to a point where they have become, well, software engineering tools
If you are talking about business software, your view is not correct. Applications that have a lot on the line (=support entire businesses) tend to use proven and tested components (think SAP, think trading engines, think SharePoint...)
If you are talking about online applications, like forums and such, then again a big "yes" to experimentation.
Twitter just proved that it is a piece of junk from a software engineering and security perspective (frequent "timeouts" softened by that ridiculous picture of a whale) and now a serious security hole.
Facebook is plagued by similar problems. It kills the browser every now and then (especially IE), it times out occassionally but overall it works because if it goes down, it isn't that critical, it will be back up tomorrow.
Then there is google. If it goes down, we got Bing, we got Yahoo.
If a business-line application goes down, the entire business stops (or gets very sluggish with a lot of pi$$ed off customers). Different game entirely.
Tom DeMarco used to be a big name, lately he has been throwing platitudes around (similar to those of Richard Florida and his creative class platitudes). In the meantime, world got flat, then it got spiky again, IT was irrelevant now it is the killer again...
Does it matter?
Does it work? If it works, it matters.
The thesis might be right (can't argue really), but what you fail to mention is that as any craft vs. manufacturing competition crafts, while have survived as a niche service (we still have farmers' markets), are all but extinct. Unless you have concrete evidence that most of the people buy from farmers and not from supermarkets, I would still believe that software engineering is almost extinct, giving way to mass-manufacturing process.
Vlad on July 19, 2009 11:30 AMThe whole discussion of computer science, programming, software development, and "software engineering," versus "engineering" is just so boring and cliche at this point. We are arguing about semantic jibber jabber.
Those of you who insist that programming is just art like painting or whatever are just smoking too much pot to be completely honest.
It's more interesting to talk about how to better develop software than all this same arguments over and over again blah blah blah.
I swear, I could recite every side of these arguments in my sleep.
"Wah wah wah, 'real engineers' can actually kill people with mistakes. Wah wah wah, 'real engineers' have legal requirements that programmers don't."
Honestly, who cares? Does it make any of you feel like less of an intellectual because you aren't an electrical engineer that couldn't write a maintainable C program to save your life?
Computer Science is fundamentally different from pure mathematics, empirical science, electrical engineering, mechanical engineering, etc.
Get. Over. It.
This is a field where you use your brain and perhaps a fairly cheap set of devices. Teenage hackers are somewhat common mostly because it is very accessible and involves a lot of logic that is amenable to a certain type of person. You don't need to have access to the sort of equipment or safety training that traditional engineers have. This doesn't make it any less challenging or "impressive," if you like, to master it.
Honestly, it's just kind of embarrasing to see programmers struggle with this question. And again, it's just so cliche at this point.
Charles on July 19, 2009 11:45 AMI have to agree with Stuart and Dave Markle. What is DeMarco's definition of a software engineer or even Jeff's?
I went to school for computer engineering, mostly focused on software. If you compared our comp sci dept to the comp engr dept one is more theory while the other (comp engr) was more application of computer science to real world problems (which matches what I understand engineering to be). It's a method of thinking and applying what you know to a problem.
Those processes (guidelines), and ways to manage, seems to be what has people assuming is the only engineering aspect of software engineering which I have to disagree with. Processes and methods to manage, in all engineering disciplines, will change with time.
Most disciplines have a creative aspect to them. Programming itself is a creative act. In civil engineering creating a highway could be considered a creative act. Sure there are metrics, but what is considered set in stone today will likely change 5+ years from now. Just look at older text books.
What scares me about this blog post is that it's sending the message to budding computer scientists and software developers that they don't need to pay attention to software engineering practices. In the absense of any software engineering practices, what is the next best alternative? Glorified hacking with venerated gurus working in dark rooms churning out beautiful code when they're ready to grace the world with their creations? http://www.codesqueeze.com/why-office-gurus-are-bad-and-the-buses-who-hit-them/
I think it might be more accurate to say that "CMMI Level 5 project management is inappropriate for developing blogging platforms" instead of the general statement, "software engineering is dead." Several other comments have addressed this, that rigorous software engineering is appropriate for different kinds of projects like compiler development, so I won't belabor that point.
A true software engineer has a toolbelt of best practices, techniques, and approaches that can be applied to different types of software projects. Are you working on aileron control software for Boeing? Then you'll apply the heaviest practices possible, with complete software specifications and signoffs possible to CYA. Are you working for a startup with a vague idea, little cash, and no ROI model? Then you'll apply a lighter weight process with an iterative lifecycle, rapid prototyping, with a concentration on vetting your ideas and getting to market as quickly as possible to grab market share. Working for an open source project with no revenue model? Then hack away!
Finally, are you somewhere in the middle, working for a medium size project for a dotcom, with a dozen developers, PMs, testers, designers, and business stakeholders with an estimated year over year revenue of 1 million dollars? Then you'll want: the accountability of a medium weight software specification; usability testing to validate initial business ideas; software estimation to determine milestones and deadlines for business commitments; software processes to have repeatable release practices; iterative development to verify that your estimates are correct; and automated regression testing and unit tests to reduce bugs in your delivered software.
Software engineering means different things to different developers. Many of the detractors of "software engineering" view it as unnecessary documentation in the way of getting to the fun part of coding. But you have to remember that software engineering is more than just generating paperwork. It's about knowing what SDLCs are available to the practitioner, such as RUP, Iterative, Scrum, or Waterfall. It's about knowing that estimation and setting milestones is a good thing when you have commitments that you need to adhere to (it's easier to steer a ship around an island if you know its location well in advance). Using project management software is appropriate if you need to make sure you're still on track for hitting your milestones. Requirements analysis and change control is good if you have a client who keeps trying to add features to the product that threaten to compromise your milestones (death by a thousand papercuts). It's about knowing that commenting your code and documenting your interfaces and APIs is a good thing if someone else needs to know how to maintain your system when you're gone (see 'hit by a bus' above). It's about having repeatable successes by documenting the processes used to get the product to production. It's about using unit testing to prevent new bugs from cropping up when you make changes to your system, and verifying that old bugs stay fixed.
I don't believe that software engineering is dead; otherwise we would all give up on unit testing, setting milestones and deadlines, and writing comments in our code. Knowing that Coding Horror is an advocate of unit testing, I know this is not the case.
Part of engineering is about knowing your goals and constraints, the tools at your disposal, and how to navigate tradeoff space to achieve your goals. We all operate within a constraint space to do what we do best. I absolutely know that I can't let 4 developers do whatever they want for 4 months to deliver a million dollar ROI project, so I apply software engineering to achieve the business goals within this constraint space. I apply the right dose (this is where craft comes in) of software engineering practices to ensure that I can achieve the business goal, keep my career, and successfully deliver the product on time.
In this regard, software development as an engineering discipline is still very much alive and strong.
digital subversion on July 19, 2009 11:52 AMI've always said that Software Engineering is, like any art form, creative. Yes, there are logical, precise and defined aspects to it that form a solid base, but once that foundation is laid then the rest, for me at least, is very much an evolutionary process. I tend to spend a good deal of time formulating in my head how a project is going to be coded, how the pieces will fit together and operate, and then I begin coding, at which point much of it just seems to 'flow', like paint onto a canvas.
One could easily compare software engineering to music. Music has a very defined scientific foundation, the frequencies/wavelengths of sounds, the precise increments for scales and harmonies, the timing of each measure. But, you take those very exact principles and you give them to, say, Mozart, and what do you get? Something wonderful! Something created from seemingly nothing.
The foundation of software engineering is what lets us compose our symphonies of code.
Curiously enough, I bookmarked this article from 2005 a couple of days ago...
"Computer Science" is Not Science and "Software Engineering" is Not Engineering - http://www.geocities.com/tablizer/science.htm
Andre on July 19, 2009 12:01 PMI guess you could say we solve problems, but are we using mathematical principles to determine if a solution will work in the same respect that engineering needs to assure that materials have the appropriate tensile strength when building axles?
For business applications, many times we are just validating premises. TDD helps us validate that we have created an answer to an abstract story. But what engineering practice conducts QA with "Should-defy-laws-of-gravity" as a test case? Physics constrains what an engineer can do, while we are constrained in some cases by mathetimatics, but in many cases we listen to abstractions, answer with different abstractions, and argue about logic.
David Robbins on July 19, 2009 12:02 PMIt really annoys me that people insist on black-and-white definition that the process of programming a computer to do something useful to humans is "engineering".
One might insist that the process for turning a tree into something useful to humans is "engineering". This immediately puts chopping firewood, making a coffee table and building a covered bridge in exactly the same category. Fail.
The same metaphor applies appropriately to ANY application of skill. It's the intent that dictates the precision required and the risks assumed.
Rick Cabral on July 19, 2009 12:04 PMExcellent post from Phillip, and it's how I feel -- I think half the time lately with Jeff being lost on me, I never even check the article from my news reader. It's not like I can block Jeff out. I could use a filter, sure, but I just do what I do with other authors, because once in a while, like the 2005-2006 days, Jeff might write an article on par enough to warrant my time.
Patrick on July 19, 2009 12:12 PMThis is not new
Even the long forgotten book "the Man-Month Myth" explains why software development isnt engineering.
I've written about it some time ago:
http://design-to-last.com/Technical/software-development-is-it-engineering.html
Daniel
daniel on July 19, 2009 12:19 PM> what we do is craftsmanship, not engineering.
Maybe you do, I do both; although perhaps I do engineering, and software development, and not software engineering? In embedded systems there is a lot of engineering. Whether 'software engineering' exists, or is worthy of recognition as a distinct discilpline may be up for debate, but I am an engineer, and I build software. Perhaps software is just a tool in my engineering toolbag.
Software development in the realms of web development, corporate management systems, and banking are probably not 'engineering', and probably never where. I've always believed that, but maybe that is because I am a 'real' engineer, I resent the abuse of the term, or am just a snob.
In my work I need to know about FIR filters, fast Fourier transforms, control theory, decibels, Shannon theorem, the Nyquist limit, and plenty of other stuff that 'real' engineers need to know. I doubt any of that ever enters the domain of a lot of software development.
However plenty of good software, and a lot of dross too remains 'crafted', and I have no argument against that. Most software develpers like the cache of the 'engineer' moniker perhaps, but most also resented the constraints ane 'methodologies' that were then imposed on projects to try and turn them into 'engineering'. They lack the necessary discipline, and just don't get it, and because the good ones are also smart, they can see that much of it is nonsense; and that's not how to get good work out of people.
I once challanges Stephen Mellor in a panel session at a conference. He was advocating Model Driven Architecture
Engineering is hard, let's go craftsmen shopping!
Yeah, we could apply actual science to our trade, but tell you what, that doesn't 'feel' right. It 'smells' bad.
Whew, thank goodness, now I don't have to actually study that hard, I don't really need to understand math or CS or anything else that requires judging people on predictable and reproducible results. We're all artists, interpreting as we go along!
'I can't teach you what I do, you just need to experience it, and you, in time, will one day be like me and one with The Craft'.
Jeff, you're the George W Bush of software, and that 'feels' like the truthiness thing to say. Craftsman bullshitters are the Republican party zealots of the trade, 'feeling' their way through recycled old ideas with new labels.
Occam's Razor: (a) Craftsman/Software consultants want you to think this is a high value art that they can only do or (b) Software consultants just tell people that they can only do their art like they do so they get paid more.
It's basically a 'I use my imagination, I have value!' circle jerk of self naming bullshit.
PS Did you know Joel worked at Microsoft once? He invented Excel but them left to invent bug tracking software. His blog used to be good, but not so much now as it's mainly adverts for those desks he sells...
> I once challanges Stephen Mellor in a panel
> session at a conference. He was advocating
> Model Driven Architecture
Oops, a little finger trouble withe the browser there!
As I was saying. I challanged him on why I should follow his advice after just ten years earlier following his advice on structured methods? He just smiled and said "this way I continue to sell more books".
Clifford on July 19, 2009 12:56 PMThe question is whether this is a first ripple of a sea change in software development or a random raving of a man losing his mainstream presence in the field?
Will the armies of PMO bean counters begin to be dismantled as low-value projects are canceled? Or will these remarks be ignored with business as usual dominating until nobody but soulless coding drones are left scrumming away to the tune of a Project Plan timeline?
DevMan on July 19, 2009 1:03 PMMake sure a distinction is made between software engineering and computer science. I rarely think about sorting. Etc. For example.
A good process can make or break you I don't care about yr hot shots. If you've got thousands of live customers, you have to have a process. Perhaps that's more bus driving than anything, but mechanisms must be in place. Again, perhaps that's not engineering software...
Also, are we talking dead like elvis or dead like punk rock?
Beware of smart people in control of their destinies making grand pronouncements about an entire industry of devs often not in control. (Ordering rhinestone keyboard...)
ruiml on July 19, 2009 1:07 PMGuys, you're arguing about nothing. Your mistake is your assumption that (non-software) engineering is devoid of creativity; that it is nothing more than a monotonous, rule-based, turn-the-crank process that yields predictable results. Well, nothing could be further than the truth. Ask any PE what they do everyday, and much of it will involve hours of brainstorming, debating design tradeoffs, consultation with the customer... in other words, the exact same things we do.
Similarly, the assumption that there are no rules in software engineering is ludicrous. I spent 9 years developing embedded safety-critical aerospace and transportation applications, and believe me, we have rules aplenty. But really, reality is your main constraint in any engineering field. There's no rule against using an O(n^2) algorithm, but you'll be sorry you did. You learn this, and put it away so you don't do it. That's a rule. That's how rules work in any engineering field.
On the other hand, the rigidity of rules and processes should be commensurate with consequence of failure. When you're writing code that flies a plane, you bet code reviews and unit tests are stringent as hell. When you're writing Solitaire, well, meh.
But more importantly: rules and rigidity don't make your product any better, or make effort estimation any easier; in software engineering, or any other engineering field. What makes your product great is your passion for creation, your thirst for always refining your craft, and your sense of esthetics; and your desire to make something great with others like yourself. How is this any different in software engineering than any other engineering field?
Engineering deals with what isn't entirely predictable. Accepting that something is incomplete and dealing with it is the difference between engineering and the accurate sciences.
It seems to me that in software we re-realize again and again, not because of the nature of our profession, which is not at all different from other engineering professions, but because of the nature of ourselves.
Being software people we're used to the accurate, and thus we find ourselves surprised when our accurate code grows around it such unpredictable and inaccurate world.
(Excuse me for going philosophical)
- Asaf
Asaf R on July 19, 2009 1:12 PMBy the way, if you guys work in a place where you actually make a physical product, and not just pure software, amble on down to where the hardware and mechanical guys sit and just observe. You'll find that those engineers don't do things much differently than you do.
Dave on July 19, 2009 1:14 PMControl is needed not for completion, unlike other disciplines, but for sustaining Software. Maintaining Semantic Hygiene is the Hardest task there is in Software Engineering Management. http://www.youtube.com/watch?v=EL97C8C53ZM
-Vasu
http://blog.amusecorp.com
Good lord, that's exactly it. I remember just a few months ago having a mini rant in my place of work saying exactly what you highlighted in bold up there... "Good programming is about craftsmanship".
All the best work that goes past my eyes on a day-to-day basis is from the programmers who care the most about doing things well.
Those programmers are not the same programmers who embrace methodologies, good practices like they were commandments, and draft piles of unread, worthless UML diagrams.
izb on July 19, 2009 1:36 PMI pretty much disagree with everything Tom wrote in his article except the byline, "Software Engineering is dead." It was a bit comical to read the article, because I kept hoping that he would write something that wasn't a complete crock at some point in the article since I intuitively agreed with the byline. Sadly, I was disappointed.
Joe Chung on July 19, 2009 1:47 PMLet me do a quick google to recall this:
http://www.computerworld.com/s/article/102405/United_axes_troubled_baggage_system_at_Denver_airport
Remember? Think about the causes of this disaster. There was a lot of engineering there, however unable to preview it. There was improvisation too, when the system started to fail and, however, they carried on.
So, what was problem? Excessive planning and engineering? Excessive experience-based improvisation? Lack of any of them?
See: Is this bird black or is it white? None!! Black and white colors doesn't exist, strictly speaking. There are only different levels of gray.
A fight between black color defenders and white color defenders is useless. Engeneering vs. experimental? I won't support this fight. Both two are useful tools when used correctly.
I think the answer is always being ready to learn from other people errors, and ready to see and accept yours (this is the hardest one!)
What a load of guff! No wonder us sales people despair. No wonder we, and the upper management, want to outsource you useless lot.
Don't you get it? We don't care about whether the product is 'engineered' or not. Just deliver the product when we say it has to be delivered.
And what idiot is this Marco chap? Control? Sales and Marketing people control you nerds! Without us, you bunch of moronic navel gazers wouldn't have a job in the first place.
I only saw this web page due to going in the monkey-compound and seeing this web page up on the projector screen. While talking to the team-lead (just what are they good for?) I got reading it while not listening to him trying to explain why his 'estimate' for the delivery was a lie. Coding horror? I get that!
Ah! Marco is in the business of selling books, not such an idiot after all.
Get back to work losers!
Sales and Marketing on July 20, 2009 2:10 AMSomeone who works for a newspaper once asked we what I did. "Software developer" was my answer. To which she replied: "Oh, you must be creative then. It's almost like art, right?"
I still not sure if it purely "art". Maybe art where you're only allowed to use certain colors.
christo on July 20, 2009 2:22 AMDon't worry! Everything has a end.
Steve J. Laye on July 20, 2009 2:27 AM@codinghorror
I wonder if you've read this post "Meta is Murder". I think it explains why these discussions are dangerous.
"And consider: how is progress made in the world? By sitting around and debating the process of how things are done ad nauseam? Or by, y'know ... doing stuff?"
Sarky on July 20, 2009 2:28 AMYou dais "And yet, it's also a release. It's as if a crushing weight has been lifted from my chest...."
Don't you mean a RELIEF?
Old news.
For quite a while now, programming has been more about the creative side of creating software than the engineering methods of applying form A to problem B to get solution C. (not that this is necessarily bad, and many of those methods exist, but in a much more flexible state than most engineers would be comfortable with)
@Jon - Well put.
Jared on July 20, 2009 2:46 AMThe article is talking about "software engineering" as a means to control projects.
From further along in the article: "I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean."
Call yourself a crafts-person if it suits your vanity, but don't confuse the engineering of software (what you are doing) with the project management process regrettably come to be known as "software engineering."
Allen on July 20, 2009 3:19 AMWe're not standing on the shoulders of giants we're kneeling on the feet of midgets.
Gavin on July 20, 2009 3:23 AMThe comments to this entry are closed.
| Content (c) 2012 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email