My name is Sébastien Arbogast, I’m 27 and I’m a freelance Software Architect and Developer based in Brussels, Belgium. My main specialties are agile methodologies, rich internet application, highly productive Java development and iPhone development. Sebastien is a DZone MVB and is not an employee of DZone and has posted 26 posts at DZone. You can read more from them at their website. View Full User Profile

Software Engineering Is Not Dead!

  • submit to reddit

There’s been a few reactions lately about the Tom DeMarco article. To be honest with you, I didn’t know the guy but apparently he’s quite respected. And the reason why I didn’t know the guy might be related to the fact that he wrote a software-related book entitled “Controlling Software Projects: Management, Measurement and Estimation”. In other words, he’s the one (OK, one of the guys) responsible with all those project managers asking us for sharp estimates, negotiating them down with us, and committing on them without our agreement, leaving us with no choice but to produce crappy software and/or fail to meet the deadlines. For me, Tom DeMarco looks a lot like this Dr. Winston D. Royce dude, who first described the theory of Waterfall methodologies and forgot to write the following sentence in bold font: “the implementation described above is risky and invites failure“. No kidding!

My reaction is about the same to what DeMarco took 40 years to realize. Software Engineering is not dead, it has never lived! There has been a lot of controversy about that, some people arguing it’s more of an art, others saying it’s science, yet others that it’s more like craftsmanship. At the end of the day, the only fact that there is a controversy shows that it doesn’t fit in the hole we’re trying to stick it into. And yes, this blog is called Software Artist, but I have to tell you that it’s more as a reaction to those who are fiercely trying to “industrialize IT processes”. Oh man, that makes me angry! In the end, I have to say that the more I think about it, the more I like the idea of craftsmanship.

Because craftsmanship is all about finding the right balance between the techniques that you’ve learnt and the intuition that you have about what you’re doing. And finding this right balance requires a lot of practice. Note that I didn’t say “time”, I said “practice”. I like it also because for any craftsman, using the right tools for the job is fundamental, and once again, note that I said “the right tools”, not “the tools that everyone else is using in here” or “the tools we invested a lot of money on and we need to make up for”. And finally I like it because when a joiner tells you that he doesn’t know exactly when this wardrobe will be finished, you don’t bother him with that because the fact that it corresponds exactly to what you need, and the fact that it will last a very long time, largely makes up for this little uncertainty. And if he tells you he’s going to need another 4 days, you don’t negotiate, because if you know better how to do it faster, why in the world didn’t you do it yourself in the first place? Or why didn’t you go and buy one at IKEA?

Now after re-reading the above paragraphs, I realize that my statements might seem a little harsh and extremist (as usual). But I don’t want to sound negative here. So if you manage software people and you feel disturbed by this perspective to lose control, let me just tell you this. Software can be incredibly powerful, it can really create tremendous value in a very flexible way. And I’m not talking about allowing you to just save money. I’m talking about the possibility to develop your business and create value from scratch. But the more value you expect to create, the more you have to ask yourself whether you absolutely need to control every aspect of the software creation process. Remember, you’ve tried it before, and it most probably didn’t work as expected. But fortunately for you there’s a different approach. Empower your software team. Don’t lead them, but make their ride smoother. Don’t make them work FOR you, work WITH them. Don’t consider them as standard office workers. Instead, hire the best craftsmen you can find and trust them with your project. Make it theirs as well as yours. Surrender on this idea of controlling everything and you’ll be surprised at the result.

Software engineering is not dead, because it has never existed. Hence there is no need to mourn it. Let’s just roll up our sleeves because we have a few palaces to build for the years to come.


Published at DZone with permission of Sebastien Arbogast, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Chris Treber replied on Thu, 2009/07/23 - 3:56am

"I didn’t know the guy but apparently he’s quite respected."

For plenty good reasons. I strongly recommend you read a book or two or 10 that he wrote ("Why does Software cost so much?", "Slack", "Vienna is waiting for you"). Tom DeMarco tries very hard to convince people that they need to care about the persons who do the work, not the mechanics of hosting human resources. When you write "Empower your software team. Don’t lead them, but make their ride smoother" that is exactly what you will find in his writing, and lots of it. He revisited positions he had in the past, and had the guts to admit he sees things differently now, and why. Respect!

Though.... I agree with you that SE never lived. After having read a lof of books about requirements gathering, software architecture (my forté), better programming, people management (by authors such as Tom de Marco, Ed Yourdon, Timothy Lister, Frederick Brooks and others) and mixing that with my 15 years of work experience I'd say I gained a lot of insights and try to apply them at work.

Often I wonder though why so many insights, often from the 80s and still holding true, find so little application in the corporate world. Maybe I'm working for the wrong clients, but if a 10 stands for "optimal" I don't see more that a 2 or 3 most of the time, and while there is a lot of griping on all levels there is litte change.

I don't have an answer why a good number of people "know better", but don't apply what they know or feel they can't. Or maybe they really can't because somebody stops them. But everybody has to try to at least  Resist Entropy (


Kurt Williams replied on Thu, 2009/07/23 - 10:40am

Good article examining one side of the software estimation debate.  A few years ago I would have agreed with you, but now having been on the front lines of creating a software business I've learned a hard lesson.  Business is run on dates.  Plans have to be made.  Resources must be allocated.  Customers need to make decisions.  All that requires dates.  Software developers always hate this since we rarely know how long something will take and it's always our personal time that suffers as a result of poor estimates that are all too often thrust upon us.  But the truth of the matter is that it ain't gonna change because businesses require dates.  So, the trick then, is to find ways for us to work within dates, not abolish them and "give up control" because guess what, the guy signing your check is always gonna be in control and he's always going to think you work for him, because you do.

Also, your article pretty well bashes the gentleman who made your case years before you did.  Tom DeMarco has written so much on this subject it's difficult to know where to start.  But, since the people issue is core to this article, please start by reading "Peopleware: Productive Projects and Teams" which examines the issue in detail.

After reading Peopleware, you'll realize that Tom DeMarco isn't behind the harsh schedules.  He's been advocating what you're talking about for decades.  You might find lots of people to blame for the state of Software Engineering today, but I guarantee Tom DeMarco isn't one of them.  Seriously, go buy Peopleware.  You'll find a kindred spirit and a mountain of good advice for the business leaders you work with.

If only you can get them to read it.  Most of the business leaders I work with have enough hubris to believe they should be writing such books, not reading them.

Sandesh Tattitali replied on Thu, 2009/07/23 - 11:07am in response to: Kurt Williams

"If only you can get them to read it.  Most of the business leaders I work with have enough hubris to believe they should be writing such books, not reading them." -> Applies as well to software developers, author of original post included.

harry maton replied on Tue, 2009/10/27 - 8:52am

You sure have an interesting perspective and should give you the benefit of the doubt because you're expert here. As for me as an end customer, I don't really care about software industrialization, I am afraid this will happen with or without my agreement. The only thing I am interest in software is to find ways to run my business more effectively. I have my Trianz consultant for that, that should keep me away from any software related issues.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.