Keanu said whoa (on tape even) way more than once…
I agree, people who only program do not typically understand the engineering that goes on behind a project and are not software engineers. However, anyone who actually have to run a project, estimate a project, convince a prospective customer about the true cost and value of a project, bring the project in on time and allow it to exist in a cost effective way for a further 10 years. These people are engineers and not craftsman. It just requires hard slog and dedication and applying various sensible principles of leveraging the right people at the right time in the project. Yes it might sap some of the enjoyment out of the project for people being forced to do things they feel is ‘beneath them’ but the results are usually satisfying, if a little boring.
Hi Leonardo,
You misunderstand me. The software engineers are not working within the constraints of cost and value. They are the people who will say what the cost and value will be. The better they are at this then the less constrained they will be when they actually build the system that they just quoted for.
Anyway, I like your analogy of a computer programmer being a plumber. It is very fitting and it is also a job that anyone can do with the right training. A craftsman does things in a beautiful and perfect way and there are many finely crafted software components (which probably have a very low ROI).
A software engineer is neither a craftsman nor a tradesman. He is not the project manager, the sales person, the business analyst, the QA person, the programmer or the support person.
He is the person responsible for the technical delivery of a software project from start to finish.
He tells the project manager how much it will cost and he makes sure it meets the customer requirements at the end.
That’s it, simple.
Anyone who is not prepared to take full responsibility for these two things is not engineering the software.
I hope its more dead than alive. I’m tired of doing everything but creating software at my company. 
I say “craft” is still too good. I might concede “software craftsmanship” for something like building a new system with carte blanche to use the best techniques via the best tools, but that’s exceptionally rare in the corporate world (i.e. this is software craftsmanship). What we are paid to do is generally to fix other people’s programs, to glue one program to another, to massage a program into working, to decipher the mysterious behavior of badly-written software. I think better names would be software plumbing, or software carpentry.
No HTML? Where I said «this is software craftsmanship», I meant this: http://schematics.sourceforge.net/ .
@Glenn: craftsmen certainly know about function. Craftsman make suits, clothing, tableware, ceramics, knives, furniture. Software is really close to craftsmanship, except most craftsmen care more about the quality of tools and results than most software-oriented companies.
Architects are even further away from programmers. When was the last time you saw an architect being rated by number of blueprints produced in a month, or by the number of housing problems solved? Yet programmers are routinely rated by lines of code or bug count. Dijkstra or Knuth would perhaps rate as software architects. The industry has no jobs for Dijkstras or Knuths.
@Robin: designers and marketing people also works under the same restrictions for cost and value estimations, project maintenance, and results. Nonetheless, no one calls them «usability engineers» or «sales engineers». Go ask a real engineer (say, a civil or chemical engineer) what’s his job like, then you’ll be able to spot the huge gap between it and so-called «software engineering».
How about lean/agile software practices?
Regression testing
Continuous integration
is that software engineering?
Because I think everyone starts being a “craftsman” in programming … individuals should be craftspeople, but teams should have a structure.
I lean towards craftsmanship myself, along with being an artist and architect. I explored this topic on my Software Results blog (http://softwareresults.blogspot.com/).
The whole discussion so far (apart from a few comments) goes in wrong directions thanks to the ambiguous meaning of the term “Software Engineering”.
I once took a university course called “Software Engineering”, expecting to learn how to design and implement software “the engineering way”. My initial fascination came from the wrong impression that I will approach building software in the same way as an engineer designs a car or a plane - picking the optimal solution given a set of constraints. I quickly got vastly disappointed and what I realised was the course should well be named “Software Manufacturing”. Why I came to that conclusion? Well, the last thing that mattered in the assessment of the coursework was the structure and the design of the delivered software. Instead, a trivial kind of Java application was to be developed through a mindlessly formalized development process, producing hundreds of mindless formal artifacts irrelevant to the problem domain, totally eliminating any room for ingenuity and innovation. In short, this course just tended to reduce software to something that comes out of an assembly line being assembled by robots. Unfortunately software developers are not robots.
Indeed, trivial software can be manufactured through a formalized process, but the word “engineering” comes in play only when you have challenging constraints to consider. Fantastic pieces of software, much like some great cars and hi-tech planes, are a product of human intelligence reaching its highest levels of reasoning in the battle of struggling against constraints – be they gravity, logic, or finite computer memory and computational power. This is in its essence a creative process that cannot be blindly formalized.
Software engineering, in the real meaning of “engineering software”, is the way for the future of this field.
Read this statement "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 " and totally agree
I love watching all these non-engineers telling me what engineering is and isn’t, and how “software is special” because, like, we don’t know the solution before we start.
It isn’t, anymore than any other real engineering starts with solution as a given. If it is, then you don’t need an engineer (except, perhaps, to check that the standards have been followed)
Engineering is about the unknown and/or hard maths. Everything else is management-guff; technical documentation or skilled-technician grade work.
It’s not that SE is dead - it just was never alive. It was a name for some university course - a way for academics to scoop out some pocket money from wannabes to make them feel like professionals.
Real professionals knew for a long time there is just a hard work with a lot of thinking about every step you take.
Tom DeMarco’s article is interesting, however I believe it has been made intentionally questionable. It just shows the trend in the history of SLCMs: from nothing to waterfall model, then to iterative, then to early XP and Scrum, then to modern Agile, and … What’s next? Tom suggests it’s commom-sense-based anarchy. I doubt it really is. More probably it will be kind of mix: Like AUP, but better defined than it is now.
In 2001 Richard Gabriel wrote about a Master of Fine Arts in Software (http://www.dreamsongs.com/MFASoftware.html)
The way that a software developer wants the user to get the information is “craft” but the way that the software developer has to write the code to perform that function is “engineering”.
Software Engineering has, in general, been the futile attempt of bureaucrats to get rid (to not need) creative, irreverent programmers. It’s sad that so much money got wasted in CASE, UML, and now BPM tools, instead of in workshops, study groups, mentoring, and training.
This all sounds very trendy but it’s ultimately pointless, pedantic, and unhelpful.
Love this Atwood - thank you for writing exactly what I’ve been thinking but not knowing how to put into words. Particularly like that you called out the arguments about reliability and scale. Software is craftsmanship with some additional parameters - but the additional parameters do not imply that it is engineering. Thanks again, man.
I much rather tile a bathtub surround when it comes to “craftsmanship.”