All,
I have a question on how people think refactoring fits into FDD. It doesn't seem to fit to me, but I would still want to evaluate feature priorities including a refactoring task. In general, after reading the practical guide book, it seems like there is a lot of emphasis on the PD or the business area and not much cohesion between that and technical development aspects even though the book talks about UI and SI layers.
Thanks
Aaron
It Fits
Hi Aaron,
refactoring has come to mean different things to different people. As a blanket statement for the continual rewriting of existing working code, then no refactoring is opposed in spirit to FDD. As simply describing the kinds of changes that are made to code, then yes refactoring fits with FDD perfectly. As you do BBF classes are being incrementally built up - feature by feature. As each feature touches an existing class, refactorings may apply. I see this as business as usual development.
I don't understand your comments re: cohesion between pd and technical development aspects. Can you try asking that question again?
Jeff
More Info
Thanks...I'll try and explain further.
In terms of refactoring, I'm looking at it from the standpoint of rewriting code to make underlying technical design improvements.
In terms of cohesion, I'm looking at a project which is in the maintenance phase. During the maintenance phase, you could have a incremental release which includes new features, bug fixes, and code refactoring/improvements (time was short in the 1st release, now we need to do some cleanup).
The planning the features obviously fits with planning feature development, but how about the other two? In terms of evaluating slippage, it would seem that you would want to take into account the other two. For example, I may have a bug which is low priority but time consuming to fix which could be dropped vs. dropping a particular feature.
In general, I'm unclear as to how ancillary tasks which could be unrelated to client features fit into the planning process. They don't seem to have any visibility because they wouldn't be on the feature list (if I understand the contents of a feature list). FDD makes sense for a new project, but I have troubles aligning the concepts to an existing project and the tasks which go along with it.
Thanks,
Aaron
Features describe what is to be done
New project, existing project, no difference.
You create features for the things that need to be done. That is, you create an FBS. Features in the FBS could be describing new functions or describing the things required to fix something (a defect against previously completed features) or...
In your example, you simply create features that describe the "new features" and the "code/refactoring imporovements."
Try reading these two threads for previous discussion on this.
Here and
Here.
Definition of "Feature"
I had read both of those previously and unfortunately they didn't answer the question well enough for me.
I assumed there isn't a difference but I wanted clarification. In my mind, the definition of feature isn't quite that broad. A feature, to me, is something that the system will do and is a decomposed user (customer) requirement. This makes sense when you apply the pattern of action-result-object. This is how I've interpreted what's in the practical guide book.
So, based on that, I didn't see bugs or code improvements fitting into the process and wasn't sure if they were supposed to be monitored outside of the feature list. Well, I guess to clarify, I can see some refactorings being classified as features, like refactoring which results in performance improvements. Bugs seem strange since more than likely there was an original feature defined and the implementation of that feature is broken. It ends up being feature to fix a feature....kind of strange.
It would be helpful to see an example of a "bug" or "refactor" feature set and how the features in that set are defined using the action-result-object pattern.
Thanks
Code cleanup and non-functional
Hi Aaron,
ok I understand much better what you're saying now. You've actually raised several different topics.
Stating that a feature is something that the system will do and is a decomposed user requirement, and stating that defects and refactoring (the code cleanup kind) are not user requirements, does lead you to be able to say that defects and refactoring don't fit the process. I agree!
So, there's a few ways to look at this. One aspect is whether a feature being client-valued is a goal or a law. Another aspect is to do with writing processes for the majority cases.
To take your refactoring as code-cleanup (no extra or changed fuction being deleivered to the client) case as an example. Yes, my FDD processes don't specifically talk about how to describe that refactoring work as it's not a path that should happen in an FDD project. What you do about such a situation really is a case by case basis. Often, I will say, my approach to this kind of activity is the tiger team approach. That is, a small number of "gun" programmers that will be tasked with the cleanup work. Now, you can still use the same sort of tracking and reporting that FDD uses, the only difference here is that the things being tracked and their structure is more like a WBS than an FBS. You are correct - you can't write client-valued features for code-cleanup since nothing is changing for the client. There is no new function or changed function. (you can, however still think about the things being done rather than the task setups to do them. This is the client-valued as a goal not a law part).
The FDD processes and writeups don't talk about how to do large code cleanup because the whole approach of FDD is to never create that situation. Where you inherit it - see above.
For defects and maintenance type work that's not always the case (although sometimes it can be). You write code that implements a business rule. The business rule is wrong (a requirements defect). You are doing functional work now and it's easy to write features that describe the function.
Jeff
That answers it
Hi,
This much more what I was looking for in terms of the process.
This helps. I won't be able to approach it quite the way you are talking about however. I don't have a large enough development team to make "gun" programmers. That's part of the reason why I wanted to get an idea about incorporating everything in to the same feature list. We need to consider everything when deciding what to drop for a release.
As far as this statement goes:
"The FDD processes and writeups don't talk about how to do large code cleanup because the whole approach of FDD is to never create that situation."
As a startup company, I think there are often trade-offs made to get a product out the door (especially if you have a small team), and the code-cleanup might not be large, but it can still be significant.
Agreed
Hi aaron,
glad we finally connected on your question. re: your closing statement - I agree.
Jeff
Bug to Feature
I'd like to add that I'm going to tell QA tomorrow that we don't have bugs to fix. We have new features to implement! :)
Bug to Feature
If you take the minimum marketable feature veiw (MMF), here, what happened was that you didn't deliver the complete feature the last time, so now you have to continue work on feature. Instead of saying you are working on a bug, just say you are working on the feature again. So bring up the old feature and add it to your list. That way, the only thing on your list will be features.
When you fix a bug, you may actually be adding value for the customer. Creating the bug means that the promised value wasn't delivered the last time, but the customer paid for it anyway.
It's not Bug to Feature, but Feature to Bug to Feature.