« Welcome new Blog Friend!| Main | Abrupt Climate Changing. Political Argument Dynamics Unchanging »
Explaining Modeling
I have been talking to some friends who are more into Agile with a big A than I am over the past couple of weeks. One of the topics was the purpose and use of modeling in developing software.
On one hand, people say its all emergent -- put a bunch of really smart people in a room with the Product Owner and fixed time-boxes and the conversation and code will follow along naturally. I don't think there is any denying that it's a true statement that software can emerge from shared conversations about problems.
On the other hand, there's the role of modeling in software development. Diagrams seem to help people understand and talk about things better, so couldn't they be part of a conversation as well?
I've been struggling with this, especially as a software and enterprise architect. Seems like people believe that modeling is part of the mindset of waterfall: that is, all the analysis happens, then all of the design, then all of the coding. In this worldview, modeling and modeling tools are just tools to control everything from the top down. It's a world where the "good" programmers control things for the "average" programmers. And when you model, you're not exactly doing one thing a time, are you? It's not like you're buying a story and going to make something of value happen for the Product Owner.
How to reconcile the good of modeling with the good of agile?
I think we naturally realize that it's a false choice: you can very well model and work in an agile team at the same time. So this was my first position: think of modeling as a way to have a conversation of a technical nature. As the team is talking about the problem domain, those who are good at modeling can sketch out the concepts -- make a domain model. And as the developers are talking about how the solution is going to work out, somebody can certainly describe this conversation in terms of something like a class model.
But that solution only held so far. My friends work in a large environment where everybody can't be in the same room at the same time. And it's no like you can work with huge corporate database systems without a logical data model. Where the heck does a LDM fit into Agile? I have people telling me that it doesn't fit into agile, which somehow doesn't make any sense.
Same goes for a component model, or a deployment model, or a requirements model. These things are tools, sure, and I wouldn't recommend anybody doing them just for the sake of doing them. But at the same time, the conversations they represent are so complex and nuanced, happening over a period of weeks sometimes, that I think they have value outside of simple conversational notes.
I realized that my desire to accommodate my friends was leaving me in an uncomfortable position. Surely the conversation was the important thing about agile. The more we moved away from the free and open conversation with our Product Owner the less agile we were going to be. We would start letting the document be the thing instead of the conversation.
It occurred to me that when we talk behavior alone -- i.e., use cases and perhaps activity diagrams representing what happens in the use case -- these are certainly simple conversations. "I put in the amount I want to withdraw and the money comes out, unless of course the balance is low, in which case I get a message" This is simple English. Got a question? Ask the Product Owner -- he's right there. He tells you what he would expect, and you make the system do that.
But what about structural questions? "When you said 'account balance' in this conversation did you mean the same 'account' as you did in that conversation we had last week?" "How many accounts can a person have? Can they have a relationship without having any accounts?" these types of questions are related to structures in the problem domain, not to behavior. The questions and answers to these types of questions can pop up as side notes in all of the other conversations. Trying to keep track of all of these questions and answers on story cards sounds like a total fantasy to me. And I can see having a slew of questions like this for even the simplest of programs.
I can see how these structural concepts are captured and modeled in some teams -- I watch it while they are estimating. Somebody says "What size is User Story X?" and then the developers do it. They sit there, staring up into the air, while they review all of these design details in their head. I can hear them muttering to themselves things like "Yeah, is that a buffered array or a flat structure?" and such. Sometimes things like "Yep. We could do that if we used the paging mechanism for that other module"
I can understand not thinking much of these conversations -- after all, they're only estimating. But do you think that if the information was important to know for the estimate it might be important to remember for the solution? Wouldn't it be a sane and rational idea to keep track of all of these ad-hoc design and solution details in some place where we could make sure they were coordinated? Wouldn't it be nice to know that the same information that developer A is using to estimate is also available to developer B?
So I can't shake MDD -- the UML model as a tool for teams, agile or not, is not something that I think can be replaced at all. Those of you telling you that you can replace it either don't know software development or haven't thought it through.
Maybe I'm smoking crack, but I can't see going into any project of any size without being able to model as necessary to capture and converse about dense informational structures that don't lend themselves to vernacular conversations.
Leave a comment