Feature Driven Development

Darya,

it's hard for me to know exactly where you're pitching this. I'm not entirely sure we have the same meaning for framework in mind.

They can be good where the cost of doing them is ok and they can actually be reused effectively. That is, without one having to fight against the thing to be reused or to try and make it fit into a different set of semantics. Reuse for the sake of reuse is not necessarily a good thing.

There are all kinds of reuse. For example, we can reuse knowledge.

No, don't rush to that judgement.

"You" is a real problem word in that paragraph. When you say "you" - who is that person? The first several times I read it I thought "you" meant me. Now I think "you" means anyone. What I write now assumes "you" means any person in general.

(side note: this is a great example of "you" as a disconnect in the straight-talk section of the workshop. look back on those slides sometime)

There's a lot of ways to reduce the time it takes to do something. There's an implicit assumption in what you're saying that reusing code is the only way to do that. What percentage of the SDLC is coding?

One can certainly reuse knowledge in a case such as you describe - and that does not even have to mean domain specific knowledge. Let's say a project manager hires some really talented people to help him on some project. These people are experienced color modelers and have significant application design and development experience. A-class developers as I call them.

The injection of those people, and the knowledge they will reuse, will have a dramatic impact on that project. And these people may not even have any domain specific knowledge. They know how to model. They know how to design. They know how to code. There's all sorts of reuse happening there - and they will produce faster because of it. But they are not necessarily reusing previous lines of code, line by line.

Don't get me wrong. I'm not saying never reuse code. Right now, I'm just trying to better understand what you really mean and to try and get you thinking more broadly.

Ok, here I think is the big disconnect. What we talk about when we are modeling the PD for some project is the PD layer of a single application. We are not talking about some enterprise object model. The model is for the PD layer of a single app. It is how the PD code of a single app will be structured.

Here's a diagram of the application architecture.

When I say we are modeling the PD for a project we are modeling that PD layer (business logic layer) for that one app on the left (for example).

I'm not talking about some enterprise object model or even wider.

I understand the desire to go down that road. After all it is a somewhat compelling and seductive notion. And as an industry, we have been there before. Many times. And it just hasn't worked out.

When data modeling first came along many thought this is great. It is so great that we could create the one big data model for everything that everyone could just reuse. And then it was realised that, well, the whole financial industry is really something of its own (just to pick one example here) and it's sufficiently different from materials resource management that they really need their own data models. And then it was realised that the financial industry data model was problematic as banking really is different from insurance and so there could be one banking industry data model and one insurance industry data model. And then it was realised that, well, really banking in the USA was pretty different from banking in Australia. In the USA you had lots of small community banks and in Australia you had a tiny number of very big banks with big branch networks. Some did debit cards, some don't, and so on.

At this point, as an industry, the notion of such data models went away (yes I'm generalising here - there are still pockets today that believe in such things). But the notion and example can be carried forward. There could be an Australian banking data model. Ah, but AusBank1 has a strategy of lowering the cost per transaction. AusBank2 has a strategy of increasing share of certain types of lending.

Now, even if we just limit the example to lending. Then sure, within lending, the statutory and regulatory checks for lending will be the same at AusBank1 and AusBank2 (as the stat-reg body is external to both of them) but their own internal credit policies will be radically different. Not only is it that the checks are different, it is also the product types and connections and so on as one bank is entirely excluding such things where the other is explicitly going after them.

Now, this didn't work for data models. We can't go to the I.T. retail outlet down the road and buy the MRP data model (for example) and drop that in and start using it.

But we tried again when objects came along. But with objects, it is much much harder because we are not just trying to describe common data. Objects contain behaviour as well as data. So, where we couldn't get a data model to stand up across organisations, with an object model we need common data and behaviour and its structuring to stand up across organisations.

At the framework level Taligent (IBM and Apple) tried in terms of OS and app development frameworks. IBM tried again with San Francisco in terms of line of business frameworks.

At the other extreme we have discrete objects (classes). It was thought we'd be able to run down to the I.T. retail outlet and buy ourselves a Customer object - ready to drop in and reuse. The same thing again with JavaBeans and then of course with EJBs (and let's just say that the "for sale" reusable bean industry is not exactly experiencing stellar growth).

Customer is often thought of as potential enterprise class. Well is it? Let's say our job is to design and build a Customer class for general reuse. What goes in it? Well, if the domain is broad this is an impossible problem. If the domain is Point-Of-Sale (POS) Cash Sales - then Customer is a class that is not even needed in that domain. At the other extreme is a domain something like a mega-CRM - then Customer in that domain is a big thing with lots of biographics in it and demographic links and so on.

Where in that continuum should we design and build our generally reusable Customer?

We can't have one Customer that satisfies all - to do so means it must be at the big extreme end which then means it is cumbersome, unwieldy and overweight for just about everyone else.

So, this kind of thing is only achievable if the domain is sufficiently narrow.

Given a narrow domain, can we design for flexibility. Of course we can and it's one of the big tradeoff decisions that are being made all the time. Peter Coad used the analogy of printed circuit boards and Java interfaces (as just one example of this). On a PCB the components can be hardwired. It's very simple and easy to understand, but it's not easy to change. A PCB can also use a socket where flexibility is needed. But PCBs aren't designed where everything is sockets. It's too costly and too complex. Similarly, a Java interface can be used for a plugin point for algorithmic flexibility, but we don't design everything as interfaces.

There are many other similar design for flexibility approaches. Here's a simple FDD model of the structure of the FBS (features list).

It's simple. It's easy to understand and it fits the FDD way of doing an FBS well.

If I wanted flexibility in this structure - for example, so that people can have any number of levels within it then I might model that like this.

A person, can reuse their knowledge of analysis, design and implementation and design and code for flexibility where required. They're reusing approaches, patterns, and so on.

Now, finally we get to reusing code. Sure that is done lots of times. UI is an easy example. You might design and build your own calendar UI component or you might buy and reuse one.

Notice how very specific the domains are now.

Ok, so switching back to root of this. You asked a question about frameworks and plenty of I.T. folk will jump in with "here's how I do one" or similar. I'm more interested in what your real problem is. I see three topics here - (1) frameworks, (2) lead time (to develop/deliver), and (3) designing for flexibility. I suspect framework is an assumption about the solution to 2 or 3 or both (?)

If the problem (and thus question) were stated differently we'd be having a different discussion here.

I don't think we have anything to add beyond what's already been discussed in this thread. We just wouldn't do things that way.

But this part is really a separate discussion from that above (this is topic 4).