"Software engineering – what an oxymoron!" and "Let's bury the term software engineering!" are rants that I recently found on blogs. Even today, many people consider that developing software-intensive systems must be more a creative activity – akin to an art or a craft – than an engineering activity in the traditional sense of applying science and discipline for developing useful products or creating value. They argue that putting the "engineering" into software engineering would kill the creative, fluid, dynamic nature of software development, stifle it, sink it under bureaucracy and restraints.

I disagree. Software engineering suffers from several misconceptions. First, it is often confused with programming, or code development – probably due to abuse of the term and job title "software engineer." Well, while programming and all things close to the program do play a part in software engineering, we could almost argue that software engineering encompasses everything but programming. You're a programmer, a software developer, good! Now you can start learning software engineering and all the concepts, skills, and techniques that are necessary to make great software products, not just nice piles of code, including the techniques and tools to avoid developing code. Second, software engineering suffers from the constant use of analogies to and attempts to pigeonhole it into civil or mechanical engineering. No, it does not require using processes, lifecycles, tools and techniques similar to other engineering disciplines. Over the last 40 years, we have developed approaches to software engineering that acknowledge its specific nature and even take advantage of its "soft" nature. Building software is not like building a bridge, because we cannot evolve and modify a bridge the way we do with software. And we have demonstrated that we can bring rigour and discipline to software engineering without having to resort to approaches derived from other engineering disciplines, which have to live within their own constraints, often imposed by the physics involved.

Hans' book on software engineering brings to both the student and the practitioner alike precisely this: a wealth of knowledge on how to engineer software – which he has accumulated, refined and decanted over the years – a palette of all the arrows outside of the strict realm of programming that a well-rounded software engineer should have in her quiver.

We are not speaking about a natural science here, where we can slowly get closer and closer to some ultimate truth. Almost everything remains a matter of opinion and is highly dependent on context. Hans and I each have our unique experience of software engineering, so naturally we disagree on some points. Life would be dull and no progress would be made if we were all patting each other on the back and not exercising our critical skills. But I can accept most of what he writes, and this is a big book, so that's still a lot.

We all know that this is not the be-all and end-all of software engineering, that our understanding of software development evolves constantly, but this book constitutes a pretty darn good baseline of proven approaches. Far too often I have seen software developers, analysts, and software managers reinventing the wheel or falling in love with a new technique or tool or some other fad. As an alternative, Hans has given a good starting point to learn about what works, and to understand where it comes from.

Yes, software can be engineered, and not quite like bridges and motors. It can be engineered with the approaches, techniques and tools that are specific to the nature of software.

Happy reading!

Philippe Kruchten

Vancouver, Canada