Hi developers. Currently I'm supporting the Agile Software Movement (http://agilemanifesto.org/) against heavy use of RUP, waterfall and others bureaucratic practices. Trying to change the organizational culture. Focus on desing, I was thinking that the task of design uml at first doesn't have sense if you could code the skeleton of your application and documenting it at the same time. Tools like doxygen make this possible, when you can specify the basic functionality of your system by documenting the code. Also many developers finds doxygen documentation easy understandable even more that a bunch of uml diagram documents, because developers got that they really need : An api description. On the other hand, RUP defensors are agree for making UML before write one line of code because they believe that there is a tool that generates code. But in practice, The effort of making diagrams is highly time consuming: building a class implies navigating for many menus, drawing , many operations, and a few for thinking. Then progammers must code that diagrams. Two tasks. On the other hand, writing the same class on code takes between 10 - 20 seconds, And you get the code at the same time. Also you can fix your design more quickly and clearly, becouse only on code you can think if that design is really efficient for managing your computacional resources. ( reducing code, reusing functionality, recycling computacional resources). And think about complex algorithmic problems. Those problems are usually solved only by programmers. It is Rarely that the designer creates those algorithms on the UML diagrams. The design must support those algorithms, and they will satisfy all performance requirements. Is common that the UML desing would be disconnected to the application reality, and is easily loose focus about the behavior of the system: There are many problems that the UML cannot predict. UML doesn't connect directly to the final plattform where the application will runs. So, UML design can be avoided, and be replaced by good coding practices. What do you think?

I also like ADM, but they generally fails when the project is large (>50 programmers). Even XP guys says it (there's no easy way to manage 25 pair of programmers without having a clearly defined goal for each one). OTOH RUP or waterfall are specially designed for this kind of projects. A team of software architect prepares the programmers work using design tools, and then the programmers task resolve to programming. Read: of course, not every programmer is involved in the design - thus, design is not a time consuming task1.

This is also what makes outsourcing possible on very big projects (something that can't be achieved using ADM).

Something else to consider: XP has been proven to be a light subset or RUP (again, this subset is still unsuitable for large projects).

There are some misconception and a bit of caricature about UML in your post. A full blown UML design also take care about the algorithms (using dynamic diagrams such as the state machine diagrams for example). Although not widespread, a correct use of these diagrams might enable you to directly generate an application - thus the UML design is connected to the reality2 (more information on code generation here). To pun Jack W. Reeves' moto, "the design is the code" in this case [smile].

BTW, we don't believe that there is a tool that generates code. We actually know it - and we also use it. Even if the design is incomplete, code generation is still quite interesting because it will cut down the development time3 (the programmers are no longer required to redo the work of the software architect).


1: I disagree with you when you describe the way diagrams are made. Remember that most software architects are also programmers, and we are used to our keyboard. Most intelligent CASE tools enable us to use it in order to speed our work.
2: again, I disagree with you when you say that "only on code you can think if that design is really efficient for managing your computational resources". If you are not able to design a system which will be resource-friendly then you won't be able to code it as well.
3: BTW, I want to see you when you program. If you are able to create a class in 20 seconds, I will propose you a really cool job [smile]

Regards,

Quote: BTW, I want to see you when you program. If you are able to create a class in 20 seconds, I will propose you a really cool job

I mean coding in 20 seconds, not thinking in 20 seconds. Cheers! :D

Meh. Waterfall, is coming back with a vengeance!:

After years of being disparaged by some in the software development community, the waterfall process is back with a vengeance. You've always known a good waterfall-based process is the right way to develop software projects. Come to the Waterfall 2006 conference and see how a sequential development process can benefit your next project. Learn how slow, deliberate handoffs (with signatures!) between groups can slow the rate of change on any project so that development teams have more time to spend on anticipating user needs through big, upfront design.

Attend these valuable tutorials:

Take Control of Your Team's Decisions NOW! by Ken Schwaber
Avoiding the Seven Pitfalls of Lean by Mary Poppendieck
Pair Managing: Two Managers per Programmer by Jim Highsmith
Two-Phase Waterfall: Implementation Considered Harmful by Robert C. Martin
User Interaction: It Was Hard to Build, It Should Be Hard to Use by Jeff Patton
FIT Testing In When You Can; Otherwise Skip It by Ward Cunningham
The Joy of Silence: Cube Farm Designs That Cut Out Conversation by Alistair Cockburn
wordUnit: A Document Testing Framework by Kent Beck
Slash and Burn: Rewrite Your Enterprise Applications Twice a Year by Michael Feathers
Very Large Projects: How to Go So Slow No One Knows You'll Never Deliver by Jutta Eckstein
Eliminating Collaboration: Get More Done Alone by Jean Tabaka
Retrospectives: Looking Back...Looking Aaaall the Way Back by Diana Larsen
The Glacial Methodology™ Workshop: A Data-Centric Software Development Process by Scott Ambler
Introduction to Dogmatic Programming by Andy Hunt and Dave Thomas
Unfactoring from Patterns: Job Security through Unreadability by Joshua Kerievsky
Honing Cut-Throat Competition Among Employees: The Art and Science of Forced-Rank Evaluations by Esther Derby
Making Outsourcing Work: One Team Member per Continent by Babu Bhatt
User Stories and Other Lies Users Tell Us by Mike Cohn
Refuctoring by Jason Gorman
Ruby On Snails: Slow Down Development With This New Framework by Dave Thomas and Mike Clark
Defect-full Code: Ensuring Future Income with Maintenance Contracts by Kay Pentecost
Testing: Saving the Best for Last by Lisa Crispin
Putting the M Back in Configuration Management by Steve Berczuk
Stalwart Analysis: The Effluvia of Determined Thought by Don Sengroiux
Pragmatic Project Chores: How to Do Everything Manually, Over and Over Again by Mike Clark
The Role of Governance in Process Maturity: We're Lawyers, and We're Here To Help by Jackie Chiles
WUP: The Waterfall Unified Process by Jon Kern
Waterfall Made Easy--The RUP Way by Per Kroll
If It Was Good Enough for Shakespeare: A Fresh Look at the Need for Talent in Software Engineering by Rob styles
The Economics of Certification by Todd Little
Pedantic Information Delivery by Mark Janney
Advanced Eclipse Debugger Techniques by J.B. (Joe) Rainsberger
Riding your Project Management Career "Over the Waterfall" Successfully by Payson Hall
Major SDLC phases: Development Driven Development and Test Driven Testing by Yury Makedonov
Working Harder, Not Smarter by Jon Kale

Quote:Original post by leoptimus

Quote: BTW, I want to see you when you program. If you are able to create a class in 20 seconds, I will propose you a really cool job

I mean coding in 20 seconds, not thinking in 20 seconds. Cheers! :D

I still hire you if you are able to do it :)

Quote:Original post by leoptimus
Hi developers.

Currently I'm supporting the Agile Software Movement (http://agilemanifesto.org/) against heavy use of RUP, waterfall and others bureaucratic practices. Trying to change the organizational culture.

Good luck!

Quote:
Focus on desing, I was thinking that the task of design uml at first doesn't have sense if you could code the skeleton of your application and documenting it at the same time.

That's actually what a UML CASE tool does, the documentation is turned into code - virtual every UML tool generates code.

Quote:
Tools like doxygen make this possible, when you can specify the basic functionality of your system by documenting the code. Also many developers finds doxygen documentation easy understandable even more that a bunch of uml diagram documents, because developers got that they really need : An api description.

That might be sufficent documentation for a C API, but for an object oriented design the class interactions are much more informative than the actual method calls they make.

Quote:
On the other hand, RUP defensors are agree for making UML before write one line of code because they believe that there is a tool that generates code.

I have to believe they know their tool generates code. But what you say is alarming - do they not know how to use thier UML tool? Is this a new effort? Do they actually not know the tool generates code? Sucessfully using UML CASE tools rest on designers that really know what they are doing. They need to know the tool quite well to be productive and need lots of domain knowledge about the product to design it well.

Quote:
But in practice, The effort of making diagrams is highly time consuming: building a class implies navigating for many menus, drawing , many operations, and a few for thinking. Then progammers must code that diagrams. Two tasks.

I agree, I can laydown interfaces in code and think through a new design much, much faster than I can using Rational Rose. There are other UML tools out there though that have somewhat better user-interfaces (a perennial favorite around here is Sparx Systems' Enterprise Architect). What these tools do much faster than I can by hand though, is create UML diagrams out of existing code. Ironic really.

Quote:
On the other hand, writing the same class on code takes between 10 - 20 seconds, And you get the code at the same time. Also you can fix your design more quickly and clearly, becouse only on code you can think if that design is really efficient for managing your computacional resources. ( reducing code, reusing functionality, recycling computacional resources).

I think I understand what you are trying to say, and this is the primary programming task whether you use UML to generate the skeletons or not. It's a non-issue. Properly exploiting the computer requires a design that aligns itself with the way the computer works. This is also orthogonal to how the design is created.

Quote:
And think about complex algorithmic problems. Those problems are usually solved only by programmers. It is Rarely that the designer creates those algorithms on the UML diagrams.

This is entirely about programming and not about design, it's non-issue on whether or not to use a UML CASE tool.

I think I am getting the root problem. Someone else will create the UML diagrams and hand them to you and you will not be allowed to change them?
This is good if the designer is more experienced than you are and very bad if not.

Quote:
The design must support those algorithms, and they will satisfy all performance requirements. Is common that the UML desing would be disconnected to the application reality, and is easily loose focus about the behavior of the system: There are many problems that the UML cannot predict. UML doesn't connect directly to the final plattform where the application will runs.

While I agree with you on this point, that the UML tends to be disconnected from the actual development, the action to take from this problem is to figure out a process or better UML tool or something else that reduces or eliminates this disconnection. It's not really a reason to give up on on UML if the organization already uses it.

Quote:
So, UML design can be avoided, and be replaced by good coding practices.

Clearly false, the statement is not sequitar - "design can be replaced with coding practices". You don't have to use UML, you don't even have to explicitly create the design before you start coding but it's still there. Good code practices should help you correctly implement the design, but somehow you must create and modify the design.

Perhaps you meant something other than coding practices?

[Edited by - Shannon Barber on July 15, 2006 3:10:00 PM]

It would be better if programmers can get tools that generate UML diagrams while they are programming, and at the same time those tools generate coding while UML designers do their work.
The software development processes must be very flexible and dynamic, because the world changes very quicky.

And why most of the Open Source projects don't use RUP?

- Many Open Source projects are still big.
- Open Source projects are developed by many people.

For example take projects like : Ogre3D, Crystal Space, Post-Nuke, PHP-Nuke, Realm Forge, Blender, Mozilla (Uses RUP?), Postgree, MySQL... etc,etc.
If those projects have used RUP in the background, then some of them must publish that UML documents. ( OGRE3D already publish only the class hierarchy, but not a completly set of RUP documents).