It seems that most people here don’t even understand what Software Engineering is. Forgive me if I read the first few comments and skipped to the end, but SE is not about “putting your head down to code”. It’s actually as far from that as possible.
Software Engineering is not a descriptor of how passionate you are about your work; to claim that “craftsmanship” and “engineer” are a contrasting duality is naive. Engineering is about how much responsibility you take, planning you perform, risk you assess, your methodology of requirements gathering, and more. They are part of engineering because they are truly quantifiable/measurable properties. In fact, the only truly “crafty”, “creative” part of software development is when you sit down to write code-- but any good developer will tell you the code is only the “20%” of the process.
If you want to call yourself a craftsman, fine; but what you’re essentially doing is calling yourself a glorified codemonkey. Someone who might be great… at only 20% of the software development process.
Great and when your craftsmanship crashes because of poor design, testing, implementation and usability I will still feel safe and secure knowing it’s not an engineering problem. Why is software any different from hardware engineering? That’s not a craft. When you build something physical it has to do the job and not crash. When you build lines of code you can just patch it so it doesn’t matter?
What the article is implying is that you can’t impose engineering principals on guys wbo couldn’t do engineering in the first place…
I never use the term “engineering”, I prefer to use “development”. I code for fun, and if I can make money doing it, awesome. Most of my software is being released free on my blog ( http://jeffhansenonline.com ) and on Youtube. It you brings joy when you get comments, telling you how great your creation is.
In my country, knowledge and technology is our main export.
We can’t predictively measure or control some of the most important aspects of a software development project, and if we try, we soon discover that the “observer effect” from physics applies to us as we end up changing the thing we’re trying to measure (and inevitably not for the better). The best we can do is to anecdotally evaluate how we’re doing by considering our past, inspecting our results, fast track cash review, and making course corrections for the future.
Not sure how I stumbled upon this old thread… but i’d figured i’d chime in 4 years later…
Its 2014, and Software Engineering is not dead. Anything attempting to create a repeatable and predictable process will NEED an engineering based approach. Agile with estimates is only as good as the accuracy of the estimates…
define your process, enforce your process, measure your process, predict your process, improve your process… how the hell can any of those concepts ever be dead???
Software Engineering is not about the code that’s written, it’s about measurement, improvement and accuracy…
Summarize time (in deep retrospect)! S3 the button and @Paul_Nathan there… Except I got a very different overview:
Software Engineering as paper planning before computer executing, is dead. Engineering as being cleaver or a craftsman, is obviously not what either Jeff or Tom meant. People won’t die if you’re not making medical software in paper before the computer. Just plug the software on people when it’s ready, evidently. It does involve both creativity and correct practice.
“Building” an app is a broad enough term that can include it being an art, sure. And code can be beautiful in many different ways. Do google for piet programming.
Keanu Reeves’s Whoa is virtually in any article opposite to Homer Simpson D’oh. Not a big surprise it ended up with DeMarco. It was bound to happen eventually.
Next topics in the chain of evolution from this general agile thought, from my own lingering memory and non-complete blog reading:
2010 Go That Way, Really Fast
2012 Todon't
2014 Three Things