Monday, July 26, 2010

Does "Software Engineering" Need to be a Profession?

[This is Part 2 of a review of Steve McConnell's book Professional Software Development. Read Part 1 here.]

In proposing that software development should become a true profession, McConnell points out that for a something to be considered a profession, it must have

  • A requirement for extensive learning and training.
  • A code of ethics imposing standards higher than those normally tolerated in the marketplace.
  • A disciplinary system for professionals who breach the code.
  • A primary emphasis on social responsibility over strictly individual gain, and a corresponding duty of its members to behave as members of a disciplined and honorable profession.
  • A prerequisite of a license prior to admission to practice.

In discussing licensing, McConnell notes

Licensing is a mandatory, legal process that is intended to protect the public, and is typically administered by jurisdictions (states, provinces, and territories).

And

One of the consequences of being a professional engineer is that you can be held personally liable for the work your company performs under your signature. Courts in the United States have held that only members of a profession can be found guilty of malpractice. Doctors, lawyers, and architects can be guilty of malpractice. Garbage truck drivers, short order cooks, and computer programmers cannot be guilty of malpractice because, legally, they aren't considered to be professionals.

No individual engineer will be required to be licensed, but some companies eventually will be required to employ licensed engineers.

Professional engineers in these companies will review software engineering work and sign off on the software their companies deliver. To those companies, employing professional engineers will be a legal necessity. If software companies follow other engineering disciplines, the company that hires a professional engineer will pay for liability insurance as part of the professional engineer's employment package, which will minimize that disadvantage of getting your professional engineering license.

Professional engineers will gain other benefits. The professional engineers who put their signature and reputation on the line for their companies will have final say over methodology choices, design approaches, and other decisions that affect the quality of the software for which they might be held liable. Without professional standing, your boss can come to you and demand that you commit to an unrealistic schedule, make shortsighted design compromises, or sacrifice quality in order to get the software out the door. With a well-defined profession—consisting of education, a code of ethics, and licensing—you will be able to say, "The standards of my profession don't allow me to shortchange quality in this situation. I could lose my license or get sued." You will have a professional and legal basis for standing up to unenlightened managers, marketers, and customers—a basis that is sorely lacking today.

Wow. In some ways, it sounds great to have a legal basis for saying no to bad development practices. In other ways, it sounds very scary to be subject to that liability.

Mostly, though it makes me wonder if software development truly needs to have "standards higher than those normally tolerated in the marketplace" and "a primary emphasis on social responsibility over strictly individual gain." It makes me want to know more about what happened to make it generally agreed that in engineering, medicine, and law, public good can't be ensured by the marketplace alone.

Because right now, one of the arguments for high standards in software development is that it's a good business decision. "The only way to go fast is to go well," as Uncle Bob Martin says. Or, we want to make sure we don't take on the wrong kind of technical debt, because that will be bad for the company in the long run.

But for a profession, these high standards don't have to be justified solely in marketplace terms. Instead, they have been accepted by society as being important for its own public interest.

In discussing how engineering came to be a profession, McConnell says:

Historically, professional engineering has been established in response to threats to public safety. Although we take the safety of modern bridges for granted, in the 1860s American bridges were failing at the rate of 25 or more per year. Bridge failures and the loss of life they caused precipitated creation of a stricter engineering approach to bridge design and construction.

I wonder what sort of disaster would need to happen for society to demand higher standards in software development. Or would a slow build-up of buggier and buggier software be enough? How many times do you need to lose your data, have your computer crash, or just plain not be able to figure out how to do what you want in a user interface before you've had enough? And if you've had enough, can you buy a competitor's software instead, or is it just as buggy?

Can the problems of today's software development be fixed by the marketplace, or do they require regulation? Does software development need to be a profession?

Sunday, July 25, 2010

Book Review: Professional Software Development

I can understand how many people sound as though they were disappointed in Steve McConnell's Professional Software Development: Shorter Schedules, Better Projects, Superior Products, Enhanced Careers. It's not a "practical" book—like Code Complete, Rapid Development, or Software Estimation—that you can immediately put into practice and improve your software's code or schedules.

But whether or not you agree with McConnell's conclusions about how to "fix" software development by turning it into a profession—like engineering, medicine, or law—it does a good job highlighting some of the ongoing struggles in developing software.

Many other reviews point out that the stratification and specialisation advocated by McConnell seem out of touch with agile development, and I agree. On the other hand, agile development encourages "generalising specialists," not straight-up generalists.

Other reviewers have also pointed out that the ladder-like professional development program promoted by McConnell also seems overly-regimented, and I agree with that, too. On the other hand, if career progression depends on taking specific classes, publishing articles, or participating in conferences, that might be better than not being allowed time for any learning or professional development at all, which happens at some companies.

[To be continued in "Does 'Software Engineering' Need to be a Profession?"]

Saturday, July 10, 2010

Book Review: Growing Object-Oriented Software, Guided by Tests

Recently, I read Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce. Amongst excellent discussions of other TDD topics, it sheds a lot of light on good ways to use mock objects.

Personally, I can remember reading Martin Fowler's Mocks Aren't Stubs quite a while ago and concluding that I'd be a "classicist."

Some time later, I started working with mocks as a way to isolate unit tests from "slow" dependencies, such as databases, trying to make them run more quickly. I didn't have much success, though, because I was still writing my tests in a classicist style.

This book helped open my eyes to how the "mockist" style really works, and why it can be a good thing. I absolutely recommend it to any programmer who is doing TDD (or writing unit tests), but who still feels like when it comes to being a mockist, they just don't get it.

I also think a great complement to the book is the video of J. B. Rainsberger's presentation Integration Tests Are A Scam.

As a note on how to read the book, I got a bit bogged down in the middle section, with the worked example. I ended up skipping to the final section and came back to the middle after. Reading it like that worked just fine. I also think it could be interesting to alternate chapters of the middle section with those of the final section.