Have you heard of SFD?

re: Have you heard of SFD?

aleonard763 — Fri, 08 Feb 2008 20:30:58 GMT

This sounds really cool. It reminds me of the "spiral" methodology some, where you started by identifying the holes in the design and then wrote little applications to demonstrate feasibility.

:{> Andy

re: Have you heard of SFD?

FKruesch — Fri, 15 Feb 2008 00:25:29 GMT

That sounds all very promsing. Looking forward to the first CTP!

cheers

Florian

Prism——finally, the P&P client team admit CAB is too complex to use！

cnblogs.com — Fri, 15 Feb 2008 10:13:33 GMT

看了P&P client product manager Glenn Block 的最新的一篇blog Have you heard of SFD? ，P&P的这些专家们总是在拼命的创造新名词

re: Have you heard of SFD?

Ben Fulton — Wed, 20 Feb 2008 20:11:41 GMT

Otherwise known as the YAGNI principle, no?

re: Have you heard of SFD?

George Birbilis — Mon, 03 Mar 2008 13:12:44 GMT

"SFD stands for Simple-First Development" - why do we keep on coining up new terms for things such as "Bottom-Up" and "Top-To-Bottom"?

re: Have you heard of SFD?

saurabhd — Mon, 03 Mar 2008 13:25:31 GMT

I am glad to see that real life examples are being used to drive the development of PRISM. I am looking forward for the first CTP.

In the Purchasing Module example cited above,I would like the team to put a thought on following scenario:

After my ERP application has been deployed to the customer, the customer's development team may want to add some more views to the composite application. Needless to say, this should happen in a pluggable way, i.e. the original base source code should not be changed.

re: Have you heard of SFD?

michael.plavnik — Fri, 14 Mar 2008 01:07:54 GMT

At the shell level we decided that we should allow modules to push views into named regions in the shell.

---------------------------------------------

Could you elaborate on your decision a little bit more?

---------------------------------------------

This makes sense because in a composite application you may have many teams that are all contributing content to the shell.

---------------------------------------------

That is certainly true.

---------------------------------------------

You don't want the shell to become a hotspot with every team having to modify it to hard-code where the injection of screens.

---------------------------------------------

It asks for big WHY? There would likely be a team that is repsonsible (product wise) for this screen. Situation would not change even in case of screen that is completely customizable by the end-user. Taken my assumption into consideration, there can be simpler solution.