Software engineering is not engineering. As a software developer, I would love nothing more than to say I am an engineer. Engineers think through and build things that are supposed to work the first time due to careful planning. So having the word "engineer" in my job title would be very cool indeed.
Let’s look at what would happen if the normal software engineering approach were applied to aerospace engineering. A plane is sitting at a gate boarding passengers, and an aerospace engineer—on a whim or forced by management—decides to replace the tail section. Because it’s just a tail section, let’s just rip it off and stick another one on right there at the gate. No problem, we can make it work! If aerospace engineering were approached like software engineering, I think the passengers would stampede to get off that plane as fast as possible. But those are the kind of changes that are made every day in major software projects the world over. The old joke is that "military intelligence" is an oxymoron, but I’d have to say that it fits "software engineering" as well. What makes this even more troubling to me is that software truly rules the world, but the approach nearly everyone takes to making it can in no way be called engineering.
Why is it that I know the physical computer I’m using right now will work, but the program I’m using, Microsoft Word, will screw up the auto numbering of my lists? While my electrical engineering friends will not be happy to hear this, hardware is easy. The electrical engineer has a limited number of inputs to work with, unlike the essentially unlimited number given to software developers.
Management also considers electrical engineering "real engineering," so management gives the appropriate time and weight to those efforts. The software business, as a distinct field, is not a mature industry; it really hasn’t been around that long. In fact, I myself am slightly younger than the software business, so my youthful look reveals some of the problem. If I were as old as electrical engineering, I’d be writing this from the grave.
Another difficulty with software development can sometimes be the software developers themselves. Realistically, the barriers to becoming a software developer can be quite low. I’m a prime example: I was working as a full-time software developer before I had a bachelor’s degree in computer science. Because I was able to "talk the talk" in interviews, I was given a job writing software. None of my employers really cared about my lack of education because they could hire me cheaper than someone with a degree.
All real engineering fields require you to achieve ambitious certification criteria before you can add the Professional Engineer (PE) designation to your name. There’s nothing like that for the software industry. That’s due in part to the fact that no one can agree what all software developers should know because of the newness of the industry. In other fields, the PE designation appropriately carries huge weight with management. If a certified engineer says a design won’t work, she won’t sign off on the plans and the project won’t go forward. That forces management to take the planning process much more seriously. Of course, by signing off on a project, the PE acknowledges liability for ethical and legal ramifications should things go wrong. Are you ready to sign off on the ethical and legal liability of your software’s design? Until we get our industry to that point, we can’t really call ourselves engineers in the traditional sense.
The good news is that even in the nearly 20 years I have been in the software development business I’ve seen huge changes for the better. Senior management is finally getting the message that software project failures cost companies serious amounts of money. Take a look at Robert Charette’s "Why Software Fails" in the September 2005 issue of the IEEE Spectrum magazine (http://www.spectrum.ieee.org/sep05/1685) for a list of spectacular failures. With the costs so high, some senior management are finally committing real resources to get software projects kicked off, planned, and implemented right the first time. We still have a long way to go, but this buy-in for real planning from management is one of the biggest changes I’ve seen in my time in the industry.
On a micro level, the best change in software development is that nearly all developers are finally serious about testing their code. Now it’s fortunately rare to hear about a developer who throws the code over the wall to the QA group and hopes for the best. This is a huge win for the industry and truly makes meeting schedules and quality gates achievable for many teams. As someone who has spent his career on the debugging and performance-tuning side of the business, I’m really encouraged about our industry becoming more mature about testing. Like all good change, the testing focus starts with the individual and the benefits work their way up the organization.
What’s also driving change is that our tools and environments are getting much better. With .NET, we have an easy way to test our code, so that means more people will test. Also, the abstraction layers are moving up, so we no longer have to deal with everything on the computer. For example, if you need to make a Web service call, you don’t have to manually open the port, build up the TCP/IP packet, call the network driver, wait for the data to return, or parse the return data. It’s now just a method call. These better abstraction layers allow us to spend more time on the important parts of any software project: the real requirements and solving the user’s problem.
We still have a long way to go before our field is a real engineering field, but the signs are encouraging. I think a big change will occur when we finally start treating testing as a real profession—one that is equal to or more important than development. While I probably won’t see the transition to software engineering before I retire, I’m very encouraged by the progress thus far. Let’s all keep pushing and learning so we can finally really be called engineers.
This book, Solid Code, is a great step in the direction of treating software as an engineering discipline. Bookstores’ programming shelves groan under two types of development books. The first kind is the hand-waving software-management type, and the second is the gritty internals-of-a-technology type; I’m guilty of writing the latter. While those books have their uses and are helpful, the types of books we are missing are the ones that talk about realworld team software development. The actual technology is such a small part of a project; it’s the team and process aspects that present the biggest challenges in getting a software project shipped. Solid Code does a great job of hitting that super hard middle ground between the management books and the technology books. By covering ideas from how to model software to security design to defensive programming, Donis and John, show you how the best practices you can apply to your development will make it even better. Reading Solid Code is like experiencing a great project lead by a top development manager and working with excellent coworkers.
The whole book is excellent; I especially loved the emphasis on planning and preparation. Many of the projects that my company, Wintellect, has had to rescue are the direct result of poor planning. Take those chapters to heart so you’ll avoid the mistakes that will cost you tons of money and time. Another problem the book addresses is the tendency to leave performance tuning and security analysis for the very end of the project. As the title of Chapter 4 so succinctly points out, "Chapter 4." The recommendations in those chapters are invaluable. Finally, the book’s emphasis on real-world coding and debugging will pay dividends even when the code goes into maintenance mode. Even though I’ve been working in the field nearly 20 years, I picked up a lot of great ideas from Solid Code.
Every developer needs to read this book, but there are others in your company who need to read it as well. Make your manager, your manager’s manager, and your manager’s manager’s manager read this book! The one question I always get from senior managers at any company is, "How does Microsoft develop software?" With the Inside Microsoft sections in most chapters of Solid Code, your management will see how Microsoft has solved problems in some of the largest applications in use today. Now start reading! It’s your turn to help move our industry into a real engineering discipline!
John RobbinsCo-founder, Wintellect