I want to ask an FDD question regarding the feature list for the DM layer. We derived feature lists for the PD, UI, SI and DM layers, however our main FDD person is now telling me that we should scrap the DM list as DM features are never client valued. He says that such development work should be amortised within the PD feature list.
The only documentation that I have found on the topic is the following thread:
http://www.featuredrivendevelopment.com/node/622
In it Jeff discusses the 4 layers but dismissed the DM layer as a layer that you never build anymore, but rather buy a solution. For a green fields project I entirely agree. However as our project has already been built using home grown data management, and considering our current release is not big enough to justify a full replacement of the DM layer, we are stuck supporting the layer. In this case should we or shouldn't we derive a DM feature list?
It depends, but a DM aspect is unusual these days
I'd agree with your FDD person's end position. It depends on what you really need. What do you gain out of another set of numbers to track and report? If this were a big project and the DM layer was significant and had a separate team, then I would make it a project aspect like UI, PD and SI. However, that's an unusual project shape these days. Since your release is small I assume your team is also and in such a case that structure just doesn't apply. The same person does the PD and DM work (and a PD feature without any DM is not interesting as a tangible result).
You gain nothing but more overhead to split out the PD vs DM aspects.
It's true that DM features are far less client-valued but it's the structural reasons above that would make me amortise DM work in the PD aspect. Which, BTW, is what I've done for years now.
Great question.
Jeff
Today I face the same problem!
Hi Jeff,
"but it's the structural reasons above that would make me amortise DM work in the PD aspect."
What do you mean by "amortise"?
In other words, in this case do you usually put the functions regarding DM in the same business activity as of client valued functions. Or you don't list them at all and put at 10-30% overhead when estimating completion dates of each client valued function of each business activity in the feature list (a.k.a feature)?
Best regards,
Nuno Lopes
Don't list them at all but include the effort
Hi Nuno,
what I mean is the latter. You don't list them at all but you account for the effort when estimating dates for each PD feature. Thus a PD feature such as "Calculate the total of a Sale" includes the DM work necessary for it.
Jeff
Amortising DM features
Hi Nuno,
regarding your first question, maybe a couple of examples might help to clarify.
First case: a constraint said we had to use a DAO pattern for persisting a small number of classes into a trivial database schema. We couldn't use an object-relational mapping tool, and so had to hand-craft the DAO implementation for each of the PD classes we wanted to persist.
We didn't write a set of DM features. For each of the PD classes we knew we had to persist, there was some additional effort writing the DAO implementation. Typically this involved the standard CRUD stuff (create, read, update and delete) and a handful of custom finder type methods. The first time we did a PD feature that relied on some persistence capability we'd add in the effort to do the CRUD stuff for that PD class to the feature's overall effort. Then the effort for each of the remaining finder methods would be added to other PD features that were the first to use them.
In practice this was quite simple. When laying out a sequence it was pretty simple to spot the first time you'd need some persistence capability of a PD class. A lot of the time you find there "housekeeping" type methods on any PD class, things like constructors and accessors etc. Where these are significant effort we have a feature for them, e.g. "specify the details of an OrderItem" might encompass all of that stuff.
If OrderItem also happened to be a persistent class, we'd also include the effort for the CRUD DAO stuff in this feature as well.
For the finder type DAO stuff it's also pretty simple in practice: a PD feature like "find by order number an Order" might include both the PD work (most likely in the Order class) and the DAO implementation of that finder method.
Another example: we did use an ORM tool. After process 1 we had the initial model shape. Since we were using Together/J for that project we also had the source code. After adding in a few return statements to make sure it compiled, we check it in to CVS as version 1.1.1.1 and we're off an running.
We point the persistence tool at the codebase, and out pops the schema. Now we're persistent.
As we build we might need to make a few tweaks to the O/R mapping. For example fine-tuning the way an attribute gets stored, or adding an index because our DBA says we need it, or adding a new class (rarely) into the list of ones the wool should persist.
Each of these are small pieces of work that get done while we're building the PD classes. We don't have a PD feature that says "create an OrderItem" and another DM feature that says "save an OrderItem". There is some DM work that happens, e.g. ensuring the mapping is ok, and that we can execute whatever queries we need to, but we can easily estimate the effort required to do this and just include it along with the PD feature that's most appropriate.
So, at the end of the day we are doing some DM work. That hasn't changed. It's just not valuable in splitting this work out into its own feature list. Remember the features list is "client valued". DM work is "plmbing" - it's there to support the PD features. So let's report it that way. We break down the necessary DM work into pieces, and attach the effort for each piece to a suitable PD feature.
Once you've chosen the persistence approach (what toolsets and/or patterns to implement) and you have a good knowledge of the PD model, it should be a trivial exercise to figure out:
- how to break down the DM work
- what PD features to attach the DM work to
- how to estimate the additional effort for each DM piece.
HTH, Paul.
Thanks for the clarification Paul.
"Once you've chosen the persistence approach (what toolsets and/or patterns to implement) and you have a good knowledge of the PD model"
If things were so simple. I rather make a rough estimation based on he complexity of the application. For instance, if I'm using an ORM, based on the vendors estimation I can cut of 20-30% from the "traditional" effort of implementating a feature from scracth (DAL and BO's). If I'm working with a legacy custom DAL then I can cut or add about 5-10% of the effort.
As of business aplications most of the BO's if not all of them require persistance, at least on the industries that I usually work. So the DM rises a cost that is omnipresent whatever feature one thinks of. In my current project (working with legacy code) I'm finding that most of the effort was in implementing the software infrastructure/architecture rather then business features. Well the project was late when I came in(4 weeks ago) and its very difficult to make people understand why it was late and why probably it will be late unless the mindset changes.
My main problem is that it took them 1.5 years with a team of 3.5 people to implement around 240 business features (too much time for so little return IMHO). All of them simple to understand and simple to implement (ex: add new content to a folder) if the focus were on the features and not on software architecture (~240 very granular features). You look at the data model and well, it even makes toasts but only 10% are actually eatable.
Nuno Lopes
Simple Things
Hi Nuno,
you say "if things were so simple" - I'm not sure which part, or both, that you're addressing here. Is it the choosing a persistence approach and/or having a good understanding of the domain?
Also, could you please clarify - what do you mean by "DAL"? Data access layer?
I don't quite understand what you're getting at with your observations about vendors claims regarding cutting X% from traditional effort? Ignoring the validity of such claims for a second, surely they'd only be addressing the effort required to persist-enable classes. As such, the overall effect on the total effort for a feature would depend on what fraction of work for that feature was persistence work.
If you're using an O/R mapping tool, this work is almost trivial. If not, you should still be in a fairly well "known" place. I'm asuming that at least someone on the project has experience implementing whatever persistence strategy you go with, be it O/R tools or hand-crafted DAO's or whatever. Given that, you should be able to estimate reasonably accurately.
If you don't have experience using the techniques / tools / whatever then I can understand why things might get difficult. But I still can't quite make the connection from this to the situation you describe where most of the effort goes into infrastructure code. You hint at the focus not being on the features - but again I'm lost. Using a features list that's not only the focus, it's the *only* mechanism to communcate both back to the stakeholders and for measuring progress.
Perhaps you could share some more information on this one? What persistence strategy did you take in this case? How much effort did it turn out to be, compared to what you estimated? Was the team familiar with the techniques you used? I'd be interested to hear your experiences.
Regards, Paul.
Simple Things
Sorry for this late reply but only now I had time to browse the forums.
DAL - Data Access Layer.
"If you're using an O/R mapping tool, this work is almost trivial."
But by trivial I think you also mean that is prety fast to persist enable a class. Fast compared to what? Compared to hand code the persistance mechanism of such class given a experienced programmer I belive.
"If you don't have experience using the techniques / tools / whatever then I can understand why things might get difficult."
I do have experience on those things becouse I do quite a lot of self learning and apply them at work. What I meant is that estimates start to get blurry when more then 50% of the team are not class A people. And that is what happens in most organizations that I've worked with. They are not class A people not becouse they can't be, but becouse "knowledge transfer" is not embedded in the the culture of the organization, so not accountable in any process. Knowledge transfer takes time, rarely its a strategic value in companies that I worked with (money is).
"But I still can't quite make the connection from this to the situation you describe where most of the effort goes into infrastructure code."
In the project that I mentioned these people tryied and to separate business logic from presentation in order to have HTML templates (a business feature). They have created a quite sofisticated mechanism base on services, pipelines of tasks, worker objects connected to roles and security constraints (similar to some open source tools).
The underlying business feature was (i'm guessing here as I see no other possible explanation for building such an architecture):
* create a new template for a site.
Now this single feature span a lot of system level architectural work.
When looking at the architecture and the main feature that was inteded, side by side one can question the architecture that was implemented. They currently face the dilemma, "Do we actually need this architecture?".
Now, one can argue that probably the implementation decisions were not the best due to the fact that a formal feature list that could be tracked was non existent, etc etc etc. But there is no point in going that way.... The fact is that this happned, it is happening and we need to deal with it.
"You hint at the focus not being on the features - but again I'm lost.
I'm lost too.
"Using a features list that's not only the focus, it's the *only* mechanism to communcate both back to the stakeholders and for measuring progress."
I fully agree with you, but that has not happened, and still the project survived. It is emazing what one can do with politics.
"Perhaps you could share some more information on this one? What persistence strategy did you take in this case? How much effort did it turn out to be, compared to what you estimated? Was the team familiar with the techniques you used? I'd be interested to hear your experiences."
As you might have guess I'm fairly new to this organization (check the end of my last post). The persintance mechanism that it was used was based on hand coding DAO and stored procedures for each class of objects. There is no PD layer, or in other words, the PD layer is embedded in the stored procedures. There is no domain model etc etc. The team is not familiar with the techniques I bring to the organization. I have no estimates to compare with within this context as it was not me who made the estimations, neither I was here to do the estimations.
So now I face the problem of estimating things while fully perceiving their, their skills etc etc. Which is a problem that is quite common in my life.
Nuno Lopes
PS: The problem I face is not so much due to a process or or lack of class A people but to culture. It takes time to change culture in away that it does not backfire on you. It needs knowledge transfer, it needs diplomacy and good communication, it need delligency, it needs results! I'm still on knowledge transfer.
Simple Things
Sorry for this late reply but only now I had time to browse the forums.
DAL - Data Access Layer.
"If you're using an O/R mapping tool, this work is almost trivial."
But by trivial I think you also mean that is prety fast to persist enable a class. Fast compared to what? Compared to hand code the persistance mechanism of such class given a experienced programmer I belive.
"If you don't have experience using the techniques / tools / whatever then I can understand why things might get difficult."
I do have experience on those things becouse I do quite a lot of self learning and apply them at work. What I meant is that estimates start to get blurry when more then 50% of the team are not class A people. And that is what happens in most organizations that I've worked with. They are not class A people not becouse they can't be, but becouse "knowledge transfer" is not embedded in the the culture of the organization, so not accountable in any process. Knowledge transfer takes time, rarely its a strategic value in companies that I worked with (money is).
"But I still can't quite make the connection from this to the situation you describe where most of the effort goes into infrastructure code."
In the project that I mentioned these people tryied and to separate business logic from presentation in order to have HTML templates (a business feature). They have created a quite sofisticated mechanism base on services, pipelines of tasks, worker objects connected to roles and security constraints (similar to some open source tools).
The underlying business feature was (i'm guessing here as I see no other possible explanation for building such an architecture):
* create a new template for a site.
Now this single feature span a lot of system level architectural work.
When looking at the architecture and the main feature that was inteded, side by side one can question the architecture that was implemented. They currently face the dilemma, "Do we actually need this architecture?".
Now, one can argue that probably the implementation decisions were not the best due to the fact that a formal feature list that could be tracked was non existent, etc etc etc. But there is no point in going that way.... The fact is that this happned, it is happening and we need to deal with it.
"You hint at the focus not being on the features - but again I'm lost.
I'm lost too.
"Using a features list that's not only the focus, it's the *only* mechanism to communcate both back to the stakeholders and for measuring progress."
I fully agree with you, but that has not happened, and still the project survived. It is emazing what one can do with politics.
"Perhaps you could share some more information on this one? What persistence strategy did you take in this case? How much effort did it turn out to be, compared to what you estimated? Was the team familiar with the techniques you used? I'd be interested to hear your experiences."
As you might have guess I'm fairly new to this organization (check the end of my last post). The persintance mechanism that it was used was based on hand coding DAO and stored procedures for each class of objects. There is no PD layer, or in other words, the PD layer is embedded in the stored procedures. There is no domain model etc etc. The team is not familiar with the techniques I bring to the organization. I have no estimates to compare with within this context as it was not me who made the estimations, neither I was here to do the estimations.
So now I face the problem of estimating things while fully perceiving their, their skills etc etc. Which is a problem that is quite common in my life.
Nuno Lopes
PS: The problem I face is not so much due to a process or or lack of class A people but to culture. It takes time to change culture in away that it does not backfire on you. It needs knowledge transfer, it needs diplomacy and good communication, it need delligency, it needs results! I'm still on knowledge transfer.
A thank you!
Szego,
Once again and within the scope of knowledge transfer I would like to thank Jeff, Stephen Palmer, you and other for sharing your knowledge with people like me. Everything you say makes sense to me and to people to whom I made a presentation about Modeling in Color, FDD and Business Patterns. I have used this techniques practice quite sucessefully in other organizations but again in the beginning I always faced the problems described.
So it is also my experience that applying the techniques of FDD (or any other actually) and the underlying techniques on an organization that it used to do things in other way it is not trivial task. And these are basically most organizations. Weather they like or not all orgs that I worked with don't yet have a Problem Domain (Model) focus on the way features are assessed and described, they are used to "blurry" functional descriptions, are used to GANTT type project management plans and more or less know how to deal with the underlying problems, are used to UI/DAO/StoreProcedures kind of technical architectures etc. They do want to change becouse they feel that things could be far more effective and productive and they see most of their problems being addressed by FDD, but they also understand that they lack on knowledge about Domain Modeling, management based on parking lots, persistant layers supporting "pure" objects and not Data Transfer Objects with no business logic etc etc is a barrier for entry.
Nuno Lopes
PS: We will soon make develop a real project (not a pilot) using these techniques but in an controlled environment separated from the rest of the teams in order for them to get the grasp on the underlying concepts and see that communication is improved considerably and so is productivity. As Jeff pointed out, it is most often unnacesary to list the features of anything below the PD from a management prepective. But people are contantly asking on this site how they can list features in these groups (DM, SI, UI, etc) and and how these lists are integrated within the FDD Framework. I consider this symptomatic of the fact how people are currently used to manage and estimate projects, and how this is intrisically intertwined with programmers tasks such as "add service to pipeline" were neither services or pipelines are objects of the problem domain.