Iteration planning for complex frameworks

I'm trying to get an idea of how to introduce agile development (or more
specific eXtreme programming) in a project for developing a potentially
complex generic framework. This framework would offer functionality to:

communication via webservices
easy (generated) extension of the webservice API
generation of ASP.NET screens

first application of this framework would be in rather big ERP applications:
a set of traditional multiplatform legacy backoffices need to be exposed via
the internet.

trying to adhere to the rule: do the most complex thing first, what would be
typical candidates for the first iterations in this example?

maybe we're too ambitious but we're also trying to convince management about
the usefullness of an agile approach. they already commited to frequent
functional discussions (ERP stuff) and development in iterations and the
fact that it probably means we cannot know now what we will have in a year.

my guess is that for the framework stuff the development team themselves
would be the customer right?

please don't tell me we don't need the framework :-( im not sure if I want
to convince management that a whole family of applications we are to develop
dont need the aforementioned framework

any suggestions?
thx
eddy


0
8/17/2004 2:01:34 PM
comp.extreme-programming 1463 articles. 1 followers. editor (304) is leader. Post Follow

10 Replies
360 Views

Similar Articles

[PageSpeed] 31

Chello wrote:

> trying to adhere to the rule: do the most complex thing first

Yeeek! Where did _that_ rule come from???

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces


0
Phlip
8/17/2004 3:02:33 PM
oops sorry, i meant: do the most risky thing first or was it: do the most
important thing first?


"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:d6pUc.1796$ZD2.1734@newssvr32.news.prodigy.com...
> Chello wrote:
>
> > trying to adhere to the rule: do the most complex thing first
>
> Yeeek! Where did _that_ rule come from???
>
> -- 
>   Phlip
>   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
>
>


0
Chello
8/17/2004 3:29:18 PM
Chello wrote:

> oops sorry, i meant: do the most risky thing first or was it: do the most
> important thing first?

If you do many high risk things first, you will start a project with a
high-risk architecture. (This explains the "Enterprise" in "Enterprise
Application Integration Patterns" etc.)

Software development follows two cycles. Deploying releases to users is the
outer cycle, and implementing features is the inner cycle.

Work the outer cycle in order of strict business priority. Do the batch of
highest-priority things first, and deliver them. Then use them to help
specify the next batch. This is a design technique and a requirements
gathering technique. Subsequent features, and their code, will support the
highest value features. All roads lead to Rome.

Work the inner cycle in order of simplicity. For a given user story, first
solve the simplest condition within it. To invent a language, make it
print("Hello World") first. Solve for several simple cases, then merge the
solutions to solve the general case.

When mathematicians write intricate proofs, such as for geometries that
generalize to any number of dimensions, they first solve a specific proof
for 2D, then a proof for 3D, then for 4D. Armed with these experiences, and
proofs, they merge duplication into a single generic proof for any number of
dimensions.

(Leaving only the multi-dimensional proof in the textbooks, to show off,
turns math books into such light pleasant relaxing reading material.)

"Designing" means organizing the relations between the structure of objects
in memory and their behavior in time. Structure is bone, behavior is muscle,
and perfecting their design is difficult. The best way to seek simplicity is
to start with it.

Now, back to your question. Remember I have never integrated an enterprise.
(Join the Saucer Section to the Drive Section, Cmdr Data!)

> I'm trying to get an idea of how to introduce agile development (or more
> specific eXtreme programming) in a project for developing a potentially
> complex generic framework. This framework would offer functionality to:
>
> communication via webservices
> easy (generated) extension of the webservice API
> generation of ASP.NET screens

How many of those acronyms are already adding value? If any are not yet, do
not deploy them until you find a reason.

Some projects start by guessing which tools they will need, then buying
them. Even if an organization already bought a given tool, adding it to a
project is still a purchase, expecting a cost of ownership lower than return
on investment. If you delay an acquisition until simple code reveals the
need for it, you might never need to acquire. If you do, your well-factored
code will specify the exact tool you need, and will insulate other modules
from the change. After replacing a module, all your tests must still pass.

> first application of this framework would be in rather big ERP
applications:
> a set of traditional multiplatform legacy backoffices need to be exposed
via
> the internet.

If you do that, whatever it means, what will end users see?

Do they want to see "your backend exposed on my browser"?

Or do they really want to see "the sales data from the Namibia office
automatically instead of via e-mail"?

They might really want the latter, but they might not know how to ask for
it. They might think that they must ask for everything, or they will only
get hacks.

> trying to adhere to the rule: do the most complex thing first, what would
be
> typical candidates for the first iterations in this example?

You are discussing requests for infrastructure. Start with requests for real
functionality. Under test, you can trust the infrastructure to emerge.

> maybe we're too ambitious but we're also trying to convince management
about
> the usefullness of an agile approach. they already commited to frequent
> functional discussions (ERP stuff) and development in iterations and the
> fact that it probably means we cannot know now what we will have in a
year.

ERP is not anti-Agile (look at Thoughtworks), but many vendors supply ERP in
huge expensive packages. They get paid whether or not you get the sales
reports from Namibia on-demand.

However, you might now also be up against any differences between what your
managers think "agile" means and what they feel comfortable with.

> my guess is that for the framework stuff the development team themselves
> would be the customer right?

Are you going to write a framework that other developers will then use to
provide features? This is a recipe for disaster because it delays feedback.

> please don't tell me we don't need the framework :-(

You don't need the framework.

> im not sure if I want
> to convince management that a whole family of applications we are to
develop
> dont need the aforementioned framework

You also don't need to be careful what you ask managers for permission to
do. Tell them that paying as you go is safe. Ask for high-value _features_,
not a payroll for a very long runway.

Implement the features, under _relentless_ testing. When you deliver, and
get the next batch of features, refactoring them together with the current
ones will grow a framework, tuned to your exact topology.

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces


0
Phlip
8/17/2004 5:10:16 PM
Always start with the equivalent of "hello world" for this type of activity, or
what Phlip has called a "closed loop" in some other discussions, or what in 
XP is called a spike.

In other words, set up a web service interface that allows access to one of the
back-office services (and maybe generate one of those ASP pages as a
result). This will get a lot the basics technical issues sorted out and will 
start to give you some feedback that will help with your direction for the 
architecture.

As you continue to develop the code, I recommend developing specific 
features rather than trying to produce a generic framework up-front. That way,
you'll get to points where the features help you to determine when you
need to refactor your framework into something more general. For example,
in a recent project, we had some things working with TCP/IP. When we 
tried to get some features working with UDP/IP, we realized things were
getting complicated. This drove us to refactor our design to support
both TCP and UDP in a generic way. I think it is better to do design
this way than to try to decide these sorts of things right up-front. 

Finally, there is no reason why agile methods can't give you an estimate
of how long the project will take, i.e. "You'll get X features in Y months
for Z dollars." The only caveat is that each iteration will improve
those estimates and tell you as early as possible if things are going off
the rails.

"Chello" <ce.borremans@chello.nl> wrote in message news:<2doUc.101434$i7.39622@amsnews05.chello.com>...
> I'm trying to get an idea of how to introduce agile development (or more
> specific eXtreme programming) in a project for developing a potentially
> complex generic framework. This framework would offer functionality to:
> 
> communication via webservices
> easy (generated) extension of the webservice API
> generation of ASP.NET screens
> 
> first application of this framework would be in rather big ERP applications:
> a set of traditional multiplatform legacy backoffices need to be exposed via
> the internet.
> 
> trying to adhere to the rule: do the most complex thing first, what would be
> typical candidates for the first iterations in this example?
> 
> maybe we're too ambitious but we're also trying to convince management about
> the usefullness of an agile approach. they already commited to frequent
> functional discussions (ERP stuff) and development in iterations and the
> fact that it probably means we cannot know now what we will have in a year.
> 
> my guess is that for the framework stuff the development team themselves
> would be the customer right?
> 
> please don't tell me we don't need the framework :-( im not sure if I want
> to convince management that a whole family of applications we are to develop
> dont need the aforementioned framework
> 
> any suggestions?
> thx
> eddy
0
vladimir_levin
8/17/2004 6:34:50 PM
> Always start with the equivalent of "hello world" for this type of activity, or
> what Phlip has called a "closed loop" in some other discussions, or what in 
> XP is called a spike.

Or a bridge thread:
  http://c2.com/cgi/wiki?BridgeThread

Laurent
http://bossavit.com/thoughts/
0
Laurent
8/18/2004 6:28:48 AM
"Chello" <ce.borremans@chello.nl> wrote in message news:<2doUc.101434$i7.39622@amsnews05.chello.com>...
> I'm trying to get an idea of how to introduce agile development (or more
> specific eXtreme programming) in a project for developing a potentially
> complex generic framework. This framework would offer functionality to:
> 
> communication via webservices
> easy (generated) extension of the webservice API
> generation of ASP.NET screens
> 
> ...
>
> please don't tell me we don't need the framework :-( im not sure if I want
> to convince management that a whole family of applications we are to develop
> dont need the aforementioned framework

You probably do need a framework.  The problem is that you really have
no idea what services the framework should provide.  I've worked on
multiple projects where such frameworks were written in advance of any
deliverable functionality, and in all cases most of the up-front work
on the framework was wasted.  A significant portion of the
functionality wasn't needed, or required extensive redesign to meet
the needs of the application.  And when used, it turned out that the
framework code had been lightly tested, and was of poor quality.  I
would never start a development project by writing a framework.

Instead, pick the most valuable application and start writing it. 
Factor out repeated code into functions, collect related functions
into classes, collect related classes into modules.  When it becomes
more important to start another application than to continue adding
functionality to the first application, start writing the next
application.  Reuse the library code from the first application when
possible.  If the library code isn't quite right, and it won't be,
then refactor it to serve both applications.  By the time you get to
the fourth application you won't have to change the existing framework
code very much, but will probably continue adding functionality.  In
this way you will develop a truly useful framework, and you won't
waste time writing a lot of code that is never used.
0
kevin
8/18/2004 5:03:05 PM
On Tue, 17 Aug 2004 14:01:34 GMT, "Chello" <ce.borremans@chello.nl>
wrote:

>I'm trying to get an idea of how to introduce agile development (or more
>specific eXtreme programming) in a project for developing a potentially
>complex generic framework. This framework would offer functionality to:
>
>communication via webservices
>easy (generated) extension of the webservice API
>generation of ASP.NET screens
>
>first application of this framework would be in rather big ERP applications:
>a set of traditional multiplatform legacy backoffices need to be exposed via
>the internet.
>
>trying to adhere to the rule: do the most complex thing first, what would be
>typical candidates for the first iterations in this example?
>
>maybe we're too ambitious but we're also trying to convince management about
>the usefullness of an agile approach. they already commited to frequent
>functional discussions (ERP stuff) and development in iterations and the
>fact that it probably means we cannot know now what we will have in a year.
>
>my guess is that for the framework stuff the development team themselves
>would be the customer right?
>
>please don't tell me we don't need the framework :-( im not sure if I want
>to convince management that a whole family of applications we are to develop
>dont need the aforementioned framework
>
>any suggestions?


Yes.  Frameworks should be developed as *part* of two or more
applications that use the framework.  You do this by starting two or
three applications in the normal XP/Agile way: Write stories, estimate
them in arbitrary points, choose high business value stories first and
implement them in very short cycles using TDD and pairing, etc.

The teams developing the applications should exchange people
frequently.  After a few iterations, it should be clear that there is
a lot of overlap between the applications.  Create a new team by
drawing a few people from each of the other application teams.  That
new team will create the framework.  The other teams will act as
customers and will feed stories.  The framework team must serve the
application teams by building generic code that implements the stories
from the application teams.  The framework team will have to negotiate
the stories with the teams so that a generic solution can be achieved.

If you don't have enough people to populate all these teams, then use
one team.  This one team will change hats each iteration.  The first
iteration they'll work on app 1.  The second iteration they'll work on
app 2.  They'll keep doing this until they learn enough to see the
overlap in the apps.  Then they'll start working on the framework one
iteration in N, and continue working on the apps during the others.


-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"The aim of science is not to open the door to infinite wisdom, 
 but to set a limit to infinite error."
    -- Bertolt Brecht, Life of Galileo
0
Robert
8/20/2004 11:07:11 PM
On Tue, 17 Aug 2004 15:02:33 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:

>Chello wrote:
>
>> trying to adhere to the rule: do the most complex thing first
>
>Yeeek! Where did _that_ rule come from???

It's pretty common.  I think Grady put it in his books.  

What you really want is highest business value first.



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"The aim of science is not to open the door to infinite wisdom, 
 but to set a limit to infinite error."
    -- Bertolt Brecht, Life of Galileo
0
Robert
8/20/2004 11:08:02 PM
Robert C. Martin wrote:

> Phlip wrote:
>
> >Chello wrote:
> >
> >> trying to adhere to the rule: do the most complex thing first
> >
> >Yeeek! Where did _that_ rule come from???
>
> It's pretty common.  I think Grady put it in his books.

I thought the iterative-but-not-extreme camp sorted things by risk, not
complexity. Meaning start with the things whose potential complexity must be
defeated, not the low-risk high-complexity things.

Probably the same difference...

> What you really want is highest business value first.

Well, you certainly have the lobes for business, O Grand Nagus of Agility.

[And you owe me 2.5 strips of gold-pressed latinum for that accolade,
indexed at 6%;]

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces


0
Phlip
8/21/2004 3:42:27 AM
Robert C. Martin wrote:

> The teams developing the applications should exchange people
> frequently.  After a few iterations, it should be clear that there is
> a lot of overlap between the applications.  Create a new team by
> drawing a few people from each of the other application teams.  That
> new team will create the framework.  The other teams will act as
> customers and will feed stories.

I'm aware that agility frees up resources, but I did not get the idea they a
VW Beetle with 30 clowns inside.

(I _did_ get the idea that a very few people had been given the marching
order: "Go build a framework, then we'l do something with it...")

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



0
Phlip
8/21/2004 3:51:23 AM
Reply: