“Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.”
http://en.wikipedia.org/wiki/Software_engineering
Licensing Software Engineers?
http://www.computer.org/portal/cms_docs_software/software/homepage/2008/s6car.pdf
One of the differences between software engineering and other forms of engineering is that software engineering rules get codified into tools. For example, Apple’s development tools force you into using a Model-View-Control design. Ruby on Rails does the same, as well as enforcing DRY (Don’t Repeat Yourself), and encouraging you to use a database rather than arbitrary files for back-end storage. Java developers using Eclipse get bad code style flagged as you type.
In contrast, a mechanical engineer needs to know the rules up front, and then test each design against those rules.
I believe their should be a distinction between what software development should be and what software development is in reality.
I still believe that software development should be a combination of craftsmanship, art and engineering.
In reality it is unfortunately often none of the above.
And people wonder why Microsoft said it will launch Windows 7 when “it is done”, and their primary goal this time is to do it right…
Don’t forget: Tom DeMarco is in the business of selling books.
Cultivating that profession since 20 years, I have intuitively come to the same conclusion, but the meaning of that isn’t as liberating as you may think.
What pisses me off is: anyone can start as a programmer, and be hired as such, without ever having served as a journeyman under one or several master craftsman, without being member of a guild, without any third party authenticated proof of his experience.
It is the typical wild west situation on a new frontier, and it is my conviction that only a proper regulation akin to the one associated with traditional craftsmanship professions can bring an unprecedented improvement in quality on all levels of software development.
Don’t panic. Software engineering and software project management are two different things. DeMarco complains about the second one.
My father is a retired structural engineer. He worked for a few large companies and lectured, but spent his last few working years at a small consultancy.
When I was a kid we built meccano together, and I can remember him working out how to get something I was trying to do to work, and saying that engineers are the people who work out how to make people’s ideas real.
Most of the work he did as a consultant was talking to the clients ( “requirements capture” ) and making sure that the builders built the right thing ( “validation” ). I can’t think of a single use of metrics in his engineering practice, which is what the ‘no, no, and no’ of the article relates to.
My career went through electronics to software ( particularly modelling of hybrid systems ). I’ve worked a bit in safety critical circles; the commenters who say that software doesn’t have design codes simply like physical engineering doesn’t work on anything that will kill people - off hand I can think of def.stan., JAA, AEC and MISRA standards for critical systems.
Fundementally, the difference between engineering and craft is that engineering artifacts are products of societies and crafts are products of individuals. You have teams of hundreds of engineers on typical systems engineering projects, some of who are software engineers. Even for small projects, you need to apply the engineering principles of breaking down a system into subsystems by purpose, function, structure and behaviour in order to reduce it to a tractable problem.
Sorry, but translating an article saying metrics only matters on unimportant projects to rejecting all engineering is bollocks. Much of what you’ve done on SO is engineering - making an idea real and habitable.
I think it all depends on the maturity of the craft itself. Sure, if you do someting for the first time, it’s craftsmanship as you haven’t done it before therefore you need to be inventive, etc.
Just as in the case of the first cars - see, there was this amazing variety of solutions for the same problem. Cars had any number of wheels from three to like ten, more types of engines you can imagine, etc. After a while, patterns started to emerge (the McPherson suspension, the Diesel engine, whatnot). Patterns are easier to use and more beneficial to refine than starting from scratch.
Fast forward to today: all the cars look the same. (still it takes 4-6 years for a new model to get out of the gates)
I see similar things in software: you have databases so you don’t need to write one. You have compilers, toolchains, standard libs, whatever. You don’t need to do everything from the ground up. Sure, there is still plenty of work to do, but a good percentage of code in probably any given software is not written by your software team (or yourself).
Sure, software is inherently easier to develop and distribute, so there is a greater diversity. However, there ARE some standards (*ML, SQL, just to name a few) and best practices you can follow. Testing is not as thorough (this is why all sw comes with a long EULA - you can’t get away with a serious problem in case of a car this easily…)
However, engineers do break out of the rules and formulas sometimes - one calls it innovation. The rest is engineering.
What I seem to see in a lot of code of clients is if it is not embeded machine code, safety critical or on a huge project like government etc then the code is bloated, full of quick hacks and generally a nightmare to read never mind work with.
So I think in smaller projects there is less care for the engineering involved.
If you had a magical replicator that could make copies of any design for free how would that change your process to make a car?
That’s software engineering in a nutshell.
It’s not that software engineering doesn’t exist it’s just that we haven’t even come close to figuring it out. The lack of physicality of software is both liberating and baffling.
Programming is intrinsically meta, because programs are a form of data. This means whenever you have some non-creative programming process, you can write a bit of software to automate it. Thus you tend to be left with just the creative parts. That’s why it feels especially “artistic”.
Normal engineering has the creative parts, but they also tend to have more non-creative parts. You can automate a factory with robots, but if you are building a bridge out in the field, you pretty much need a bunch of men with welding kits. That’s hard to automate. From a distance that kind of labour can mask the creative side.
Izkata: 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 […]
That’s because, until now, 100% of your programming has been done by yourself, in your bedroom.
I think this turned out to a pointless discussion of what it means being an engineer or a craftsman.
If this discussion doesn’t bring any improvement to the field, so we’re all losing time reading and answering all of this.
To me, building a software is constructing something that does what it meant to do. But I can build a wooden brigde, a stone one, or even a steel, or I dont know. The point is, it’s going to work ? Yep ? So let my creativity run free. (as long as the project doensn’t suffer.)
If you are reading this article, you are part of the minority that care genuinely about their craft. But that isn’t the majority of programmers.
On a real project, you won’t get all burning, committed craftsmen. You won’t even get that as a majority. And it is easy to poison a group.
You won’t get an open ticket to innovate/create… at least not forever. You won’t get turned on to, “go build the Taj Mahal”… You’ll get turned on to build a new community center in Podunk.
So how are you going to energize your programming Narcissists when it’s just a community center?
You
“Why is software any different from hardware engineering?”
As an actual engineer (Aerospace) I’ll answer your question:
Physical solutions are built upon immutable knowledge - the tensile strength of steel, the conductivity of copper. There is nothing immutable about software.
Dave Markle: “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!?”
Craftsmanship doesn’t just mean artistry, and even if it did, artistry doesn’t mean “arranging things in a pleasant way”. Being able to work out what to implement, which parts should be involved and how these parts should function internally and externally is exactly what programming as software craftsmanship is. It’s about using your knowledge of programming and of the situation at hand to create a good solution. There are tons of solutions for most problems, and those that work better than others are both finer crafted and better engineered; as far as I’m concerned, it’s the same thing.
The reason it sounds like nonsense to you is because no one actually said that. It was your straw man. Don’t make the mistake of tying craftsmanship or artistry to “beauty” or “usability” or “fanciness”, or engineering to “performance characteristics”. They are tools to be applied across all facets of the design, not handles by which you wage ridicule at poor solutions.
It is interesting that you can get a Software Engineering degree (e.g. http://www.bseng.uvic.ca/ ) and you can become a licensed Professional Software Engineer ( http://www.apeg.bc.ca/reg/pengappdocsrequired.html ), yet something like half the comments on this blog indicate that there is no such thing as Software Engineering. I wonder why that is?
If you think of the “craftsman” thing in terms of a specific craft - clockmaking - it becomes even more interesting.
Imagine the difference between designing a lot of “clock parts” that are engineered to be beautiful, precise and interchangeable, and buying these parts to build a unique clock with a beautiful hand-carved body, hand-calligraphed face, etc.
Most of us are the clock-making artisans. Many of us still need the true engineers to make the precise, interchangeable parts. We understand what an escapement is and how it works, but we couldn’t build a respectable one to save our own lives. We can use it well, though.
Sad to see an obviously highly regarded person come up with this revised view. I think he has left the real world.
The real world (where I am a project manager that needs IT now and then) has only so many chances to build Google Earths or Wikipedias - both of which have started as free/not-for-profit apps.
It also consists of many businesses that try to make money by improving/evolving through “relatively useless [marginal] projects”, as in mature businesses there are not many “tranformation” break-throughs.
The real world also changes not that often.
The whole world is talking about continuous improvement and kaizen, but DeMarco thinks it’s useless?
Agile is a great approach, but the inertia and ignorance in the IT world is also great - try and get a system built where customer focus and involvement are paramount and the system works incrementally from early on. Many IT companies still love the Big Bang.
DeMarco is coming up with a similarity of the lamest excuse in the book: you can’t standardise MY work, I am an artist.
See what crappy, ever-changing interfaces these artists build! Try and train users to work with several different behaving apps. You artists are consistently reducing efficiency.
I think DeMarco’s lost his marbles. Maybe we need to write a wonderful product called MarbleSearch!
Smells like beardy sandal spirit.
Thanks Jeff for your great site and work over the years!