Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I know methodologies, like Extreme Programming (XP), which specifies its own specific practices for developing software. However, unlike Scrum where it focuses more on management aspects, XP specifies software practices that are required to be followed. From reading this article, these steps eliminate the explicit modeling phase using tools such as BPMN and UML. In another article from Martin Fowler, he further explains such discouragement.

Personally, I prefer the model-driven methodologies I guess it's up to the preference of companies and people. One of Agile goal is to "free developers from document works". Methodology like XP seems to easily lead to under documentation. I think to achieve that goal, the solution is to implement the tool to help developer reduce the workload on writing document, not by writing less documents, by gathering information from existing diagrams and automatically generate reports (in RTF, PDF, HTML in the case of Enterprise Architect of Sparx System).

Some software engineers also complain about drawing diagrams consuming their time. In my opinion, the solution is not to draw diagram, but using the tool. Modeling tools today support round-trip engineering, where you can synchronize between your code and your diagrams, thus eliminates the extra effort to manually correct the diagrams if the code base changes (specifically, class diagram).

How does modeling fit into a team that is using Extreme Programming?

share|improve this question
1  
Where did you read that "XP specifies software practices and requires you to follow, and eliminate the modeling process"? I can find no such information. –  Thomas Owens Jan 26 '12 at 10:59
    
@Thomas Owens here is the link: xprogramming.com/articles/fussaboutdocumentation –  Amumu Jan 26 '12 at 11:10
    
@Oded what's wrong with this question? The main question is one the title. The supplementary question is in the content. What's not constructive about this question? I don't want to start a flamewar or troll, I just want to question and discuss the effectiveness of various development methodologies. –  Amumu Jan 26 '12 at 11:12
1  
Honestly Amumu, if you prefer model-driven methodologies I would definitely continue using them. Don't feel pressured to switch to a methodology where that approach is de-emphasized just because it is the latest fad. –  Antonio2011a Jan 26 '12 at 21:23
1  
I think people like Beck, Fowler have a lot of success with XP, because they have so much experience with programming and architecture that they can use a more light-weight approach. It is a mistake to generalize this to assume that XP is the best for everyone. Depending on the nature of the project, the team, and your own personal style, XP may not be the best approach. Most of the empirical evidence I have seen is not that persuasive, and it is a shame that the software engineering industry is so driven by fads and hype. –  Antonio2011a Jan 26 '12 at 21:26

1 Answer 1

up vote 8 down vote accepted

XP doesn't explicitly call for the creation of a model, but it doesn't say that one should never be produced. If developing a model helps you to build and then document your system, it should absolutely be done. The difference is that Agile Modeling has a different focus than system modeling in a plan-driven environment. In fact, the Agile Modeling site even addresses specifically how you model in an Extreme environment.

Agile environments take a more Lean (in the same sense of Lean engineering or Lean manufacturing) approach. Some of the key tenants include reducing waste, deciding late, and delivering fast. In order to eliminate waste, only the required documentation is delivered at the appropriate granularity. If you produce a work product, that work product is expected to ultimately add value to the customer - waste is considered anything that doesn't help add value to the person paying for it.

In fact, the XProgramming blog article you linked to supports this:

You may well need some nicely formatted UML for your project...If and when you really need these things, then by all means you should do them. But inside your collocated Whole Team, you most probably will not need them, because the information you need will be communicated through the more effective medium of conversation.

The Martin Fowler article that you linked to also supports this:

Certainly XP de-emphasizes diagrams to a great extent. Although the official position is along the lines of "use them if they are useful", there is a strong subtext of "real XPers don't do diagrams".

A central idea of the agile methods is "individuals and interactions over processes and tools". You don't follow a process or use a tool for the sake of following the process or using a tool. If the task that you are working on does not add value or if it doesn't produce something that is useful to someone (either the customer or another engineer), then you don't do it.

Martin Fowler goes on to say:

The primary value is communication. Effective communication means selecting important things and neglecting the less important. This selectivity is the key to using the UML well. ... A common problem with the common use of diagrams is that people try to make them comprehensive.

Again, same idea. The purpose of any documentation is communication. If you are producing things that don't help you communicate the system, why are you doing it? Don't focus on every little detail, but focus on communicating a message that provides useful, value-adding information to someone else.

Even later in the article, Fowler goes on to note that one of the problems with CASE tools is that they can fall out-of-sync. As soon as the code and the documentation fall out of sync, the document adds no value. I'd even take this a step further and say that it adds negative value, as it provides false and misleading information to anyone who tries to use it to make a decision. If you have a process to maintain synchronization, that's good. However, if you don't and you do let your documents fall out of sync, this brings up another question: why do you have them? They clearly aren't being used, or else they would be maintained.

Rather than some other model-driven methodologies requiring the models, even if they don't necessarily add any value, XP calls for spending time and resources on things that actually help you deliver value to the customer/client. If you can justify that certain models actually do add value to your project, then by all means you should produce them. However, you shouldn't be producing models that duplicate other information or don't add value.

share|improve this answer
    
If you read the whole article, pretty much the author encourages the absence of documentation. An example is his opinion about maintenance documents. He said if it is missing, it won't hurt anyone. Sure everyone can dig into the source code, but it will cost extra time rather than reading the comments to quickly grasp the purpose of a function. Yes, he mentioned the use of UML occasionally, but the above bold advices strongly discourages its usage. –  Amumu Jan 26 '12 at 11:25
    
Martin Fowler in his artical, "Is design dead?" martinfowler.com/articles/designDead.html , you can read about UML and XP to see how XP discourages modeling. However, in my original post, I mentioned about architect and mechanical engineer. People in those fields can produce very complicated drawing, and we are stucking with the UML? I also mentioned that tools help reduce the workload spent on the aspect like documentation. In fact, with round-trip engineering, I find it more productive. –  Amumu Jan 26 '12 at 11:31
2  
@Amumu I don't see anything, in either article, encouraging an absence of documentation. I'm seeing the idea that less concrete and more fluid, more just-in-time, and more value-adding documentation is better. It's still documentation, it's just captured differently. If you can say that UML adds value to your project, then you should do it. However, the argument is that on many projects, it doesn't add value, therefore it isn't necessary and shouldn't be done. –  Thomas Owens Jan 26 '12 at 11:59
    
@Amumu I just added more information to my answer, quoting areas in both articles that show that XP does not discourage modeling, but discourages modeling that doesn't add value. –  Thomas Owens Jan 26 '12 at 12:09
1  
@Amumu Read Agile Modeling and eXtreme Programming (XP), it largely supports Thomas answer (and mine, if Thomas wasn't so quick). Also, if you are interested in XP, you should really get a copy of Kent Beck's Extreme Programming Explained: Embrace Change, Kent's hand drawn diagrams are amazing! - Thomas feel free to include those references in your answer. –  Yannis Rizos Jan 26 '12 at 12:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.