 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > Software Quality News > Ivar Jacobson: Useful app dev practices trump full-blown processes |
| |
|
|
|
|
| Software Quality News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It may be surprising when a prominent software methodologist pauses to rethink processes and practices that he had a big hand in formulating. Not so with Ivar Jacobson.
The father of use cases, a founder of the Unified Modeling Language (UML), and a driving force in Aspect-Oriented Programming, Ivar Jacobson has a curriculum vitae that is somewhat unique among software technologists. Perhaps his ability to rethink his achievements is a major reason he has been able to have so many. He shows pride in work he has done, but he can be critical of that work. Take the Rational Unified Process (RUP) as an example. For more than a few developers, RUP was the last straw in a backbreaking procession of processes and methodologies designed to turn vague programmer art into solid software engineering. Extreme Programming (XP) and agile development processes came into being at least in some part as a reaction to RUP, which both XP adherents and Agilists perceived as too complex and rigid. Jacobson can be droll describing this phenomenon. The only thing the signers of the Agile Manifesto had in common, he has joked, was that "they hated RUP." RUP is very much based on the Rational Objectory Process derived from Jacobson's work at Objectory A.B. Yes, he has admitted, RUP is his baby. Yet, he has remarked on occasion: "Babies grow up, and some of them have to be corrected." RUP is not alone as a poster child for the "software process." The widely used Capability Maturity Model (CMM) came to prominence in the 1990s as a measure of organizations' process capabilities. CMM has been superseded by Capability Maturity Model Integration (CMMI). "CMMI is still about big processes. What you do not get from CMMI is good software," said Jacobson. The focus on improving the process can obscure natural faults. Jacobson has an analogy: "You pave a cow path, but you still have a cow path." Focusing on best practices If critics say that software development processes by nature become larger and larger, Jacobson does not tend to disagree. In years past, the vexing decision in the software development process often was what to include or what not to include. So-called religious wars were fought over purity of methods. Such fighting over "process" is ill-advised, suggested Jacobson recently in a phone conversation with SearchSoftwareQuality.com. A focus on useful practices yields better results.
"We always intuitively talk about 'practice.' It is basically anything -- it's not well-defined," Jacobson said. "But we can think of these practices as being composable." He suggested that teams naturally mix and match elements of practices -- for example, use cases or test cases, Scrum meetings, and so on -- that they find useful. In a series of public speeches, Jacobson has delivered the message that adopting full-fledged processes does not make sense. This came in part from his considerations of what it would take to make RUP "agile." Practice is the way, he seems to say. In effect, it is a unit of adoption that works for software teams; it is a unit far more malleable than the overarching process. He suggests that different teams can adopt different practices according to their needs, which is a far cry from the song heard during the Big Process days. "With processes, every time a new idea comes up you find yourself adding to the processes. You always are adding," said Jacobson. "You cannot take away anything because you already have a lot of users of your old process. I used to say, 'Every successful process will die under its own weight because we add more and more to it.' " Meanwhile, there are some indications that RUP is undergoing some re-evaluation at IBM. For example, IBM Agile evangelist Scott Ambler late last year discussed the idea of "Agile RUP." He said developer teams should select aspects of RUP -- which he describes as a process framework -- that they find useful. As the industry awaits more information on IBM's Jazz tool product line at this year's IBM/Rational User Group Conference, there is a sense that lighter or "composable" approaches will be emphasized. In any case, Jacobson and his crew will be there.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
