OP-ED: Process is Irrelevant

Did you attend TechEd 2007 in Orlando, Florida this year? I hope so. The weather was beautiful and the event was informative. One of the presentations I anticipated the most—and was not disappointed by—was a session by Ivar Jacobson and David West in the Architectural Technical Learning Center on Practices. If you don't know, Ivar Jacobson is the father of Use Cases, and one of the three Amigos, who co-developed UML and the Rational Unified Process. Jacobson has since left IBM/Rational and started Ivar Jacobson Consulting (ivarjacobson.com). (I was a little saddened to hear from David West that Grady Booch has waivering health and James Rumbaugh—the other Amigos—have retired.)

This is sort of a transition point in an era where software development teams are still trying to figure out how to build software predictably and reliably. What was most important about the presentation is what Ivar Jacobson had to say. Jacobson said that "process will become irrelevant." I wasn't sure I heard correctly, so I asked him to repeat and clarify his assertion, and he said "process is irrelevant."

Why is this important? Well, it seems that the process wars have just started to really heat up, but I agree with Jacobson. A single process does not fit all scenarios. Software cannot be assembly-lined because every piece of software is fundamentally a unique thing. What Jacobson (and West, whose energy is astounding) said is that Practice is more important. Granted, practice seems to be at least part of the underpinnings for Jacobson Consulting, but again I still agree that process is irrelevant and practice is more important. And, I have thought so for some time.

Practices are the elements that make up process. For example, pair programming and unit testing are practices. I can't speak for Jacobson, so I am telling you what I mean and what I think he means and heard him say. All of the processes have produced a buffet of choices, or things you can do as part of the process of building software, referred to by Jacobson as practices. It is up to the discretion of the individual teams to look at the buffet of choices and pick an assortment of practices from those available—and not dogmatically adhere to all of RUP, Scrum, Agile, or XP. So, it is okay, and in fact correct to use Unit testing, Refactoring, Use Cases, and pair programming with an iterative and incremental approach, if you want, or use some XP and some Agile practices, if you want. You compose your own ad hoc methodology from all of the available practices (that you know) based on the problem at hand. This is in fact what I have done for years.

I generally like certain practices because they fit a lot of scenarios. I like Use Cases, some UML for core parts, Unit testing, Refactoring, and Design Patterns-based implementation. By using patterns, I reduce the amount of modeling I need to do, but good Use Cases are invaluable and Unit testing helps move code in the right direction. This balance works for me. You are free to and should find the balance that works for you and your teammates.

I don't know every element of every practice. I do know some XP and some RUP, so I use practices from those processes. However, what I encourage you to do is learn as much about the practices from different processes as possible so you will have more items to choose from when you approach the buffet table.

In parting, I would like to tell you a couple of things you might find useful. Ivar Jacobson said "buy books" but "nobody reads them." It's a funny punch-line, but one wonders if he isn't spot on. The other is that I interviewed for a project management job at a local software company in the recent past, and the position seemed to hinge on knowing Scrum. This company (or interviewers) seemed to think Scrum was the answer. I don't really know that much about Scrum and was tempted to tell them that one process doesn't guarantee anything, that best practices from any process should be fair game. I am sorry I didn't tell them that. Knowing or believing something doesn't do you or anyone else any good if you keep it to yourself. The conviction of one's beliefs, right or wrong, is what distinguishes one from another. I may have not gotten the offer I wanted by stating with conviction what I believed, but I do believe that dogmatic adherence to a single process will not work uniformly and may cause more problems than it solves. Knowledge, flexibility, and the discretion of smart individuals beats a one-size fits all rule book any day.

About the Author

Paul Kimmel is the VB Today columnist for www.codeguru.com and has written several books on object-oriented programming and .NET. Check out his new book UML DeMystified from McGraw-Hill/Osborne. Paul is a software architect for Tri-State Hospital Supply Corporation. You may contact him for technology questions at .

If you are interested in joining or sponsoring a .NET Users Group, check out www.glugnet.org. Also, Glugnet is expanding into the Flint, Michigan area with glugnet-Flint. If you live in the Flint area and would like to participate in a great .NET Users Group, drop me a line or check out www.glugnet.org for more details. The first meeting will be August 2007 at the New Horizons training center in Flint, Michigan. We will be looking for local board members to coordinate events and regional sponsors and talents to provide the infotainment. Same Bat-time, same Bat-channel for more details.

Copyright © 2007. All Rights Reserved.
By Paul Kimmel. pkimmel@softconcepts.com


  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Intelligent N+X Redundancy, Placement Affinities, & Future Proofing in the Virtualized Data Center Virtualization brought about the ability to simplify business continuity management in IT. Workload portability and data replication capabilities mean that physical infrastructure failures no longer need impact application services, and they can rapidly be recovered even in the event of complete site failure. However, Enterprises and Service Providers face new challenges ensuring they have enough compute …

  • By now you've likely heard of Agile development and building products in small incremental pieces, so you can get real feedback along the way. In fact, you may even be considering using Agile on your next project. But where do you start? Agile can take a lot of forms, such as Scrum or Kanban. Each form has advantages and disadvantages, but both will help your team get the right feedback they need to build great products. Read this white paper to find out which one is right for you.

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date