WEBINAR: On-demand webcast
How to Boost Database Development Productivity on Linux, Docker, and Kubernetes with Microsoft SQL Server 2017 REGISTER >
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. firstname.lastname@example.org