Thank you so much for your extensive review. I am glad it generally worked fine for you. As you said, I’m doing my best to move FlairBuilder forward based on users’ feedback and suggestions.

Print has been indeed requested a few times now but I haven’t yet figured out how would this feature look like given the dynamic nature of FlairBuilder’s wireframes. Pages may have many states and it’s hard to capture all of them in a printed document. There is an export image option that you could use to print different states of a page.

Themes are something to be added very soon.

As for the recently opened files… point taken! I actually have the code in there but it’s not yet 90% done.

I look forward to hear more from you. I’m most happy when people find my little app useful.

Cheers,
Cristian

The fist question is a great one and I agree is to often not answered fully.

Thanks,

We do this for every aspect (UI, DB, …) in our project just as Jeff wrote above. We call these people or groups “consultants” to our core team. These consultans can come from within our company or from the customer or are hired externally.

In reply to UI vs. functional features:
We use a design similar to MVC/MVP (Passive View Command: see http://www.planetgeek.ch/2009/04/08/passive-view-command-pvc-pattern/ for a short description) to separate UI (the look and feel) from the logic (user interface logic, business logic, …)
This pattern allows us to have very little blocking issues between functional and user interface feature development. And we can change the UI (look and feel) very quickly without breaking the logic behind it. Furthermore, we can build real functioning skeletons (something like a prototype) to give our customers something to click on. This skeleton consists of the real View and Presenter, but fake Commands and Model.

1. I think FDD better fits contract based development then either XP, or SCRUM. “Contract based” usually means fixed price, fixed time and sometimes means strong customer control (especially in govermantal projects). I’ve found XP, SCRUM to be “too agile” for this type of projects. Meanwhile FDD has techniques to reduce risk in such situations(see [1]).

2. Experts say that FDD can deal with varying skill levels and can scale up. Meanwhile XP is targeting mainly seniors, and is designed to work with 2-10 programmers (see [2]). I agree with this opinion:) Namely I cannot imagine a large XP team, where senior programmers works with lower skilled ones and meanwhile the team aligns with the “Collective Ownership” principle.

3. Also note that in usual projects “mixing skill levels” means a more economic/cheerful approach then working with just seniors – since tasks are at different difficulty levels in usual projects. It would be a very expensive approach assigning senior developers to easy tasks. Also senior programmers would quickly quit in such a situation…

4. Most of the projects that I participated in involved new technologies that had been never seen before by the development team. At this point I think FDD lacks any support – thus I would say FDD (without extending it) is better suited for projects where only proven technologies applied. Meanwhile XP has technique for such a situation (eg. spikes).

But this is just my opinion, and again I could be wrong:)

Refs:
[1] http://www.featuredrivendevelopment.com/node/527

[2] http://edn.embarcadero.com/article/29684

Also how would you rate FDD as opposed to other Agile Development models?

I’m assuming you gather the features (user stories) from your customers. Do you have a proxy to the customers or is it direct interaction?

Side Note: Anyone have trouble with the comment system showing up when you are a registered user, or when you are logged out. I have a feeling there is a bug I’m trying to stamp out.

1st step: Capture user requirements; define funtions/features; design the shape model (containing both data and UI elements, and whatever layer the application has).

2nd step: Roll out an application framework early targeting basic application elements, including both server side and client side (eg. UI) logic.

3rd step: Go on and produce the software in an iterative manner. In every ~4 week iteration: design the detailed model, implement and hopefuly test it:) At the end of the (2-3 month) milestones deploy it:)

In this approach the UI expert is responsible for the basic UI features: produces/documents basic page templates, stylesheets, widgets, etc. This work is done mainly in the 2nd step, then he switches to ’support mode’.

The specific applicaton functions (including both view, and controler logic) are done in the 3rd step: planned/coded by application designers/developers. The UI expert only assists it.

Ps.: I said we tried to follow FDD, since sometimes the customer wants something else. Sometime he wants waterfall:( And after all he is the customer.