I was utterly floored when I read this new IEEE article by Tom DeMarco (pdf). See if you can tell why.
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/07/software-engineering-dead.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/07/software-engineering-dead.html
1 Like
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)
I 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.
I 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.
I 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.
âSoftware Engineeringâ never existed. Developing software is nothing like actual engineering.
1 Like
IMHO, 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?!
Wrong. 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â.
1 Like
Now that youâve given up on calling yourselves engineers, the rest of us actual engineers can stop trying to defend our profession.
1 Like
Jeff -
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
1 Like
Amen. 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).
Software 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.
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.
It 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.
Donât worry Jeff, youâre not a software engineer⌠Youâre just a VB noob.
Or C++ shudders even worse.
I 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.
1 Like
This 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
1 Like
â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?