So let's build a router

This comment is an offshoot of the XP Requirement Analysis thread.

> Laurent Bossavit (laurent@dontspambossavit.com)
>For instance Extreme Programming, to focus on one of these "newer"
>methods, does have quite a bit of planning and outlining built into it,
>especially compared to widespread "code first and tweak until it works"
>approaches. What it doesn't have is a lot of formal examining of the
>"big picture" in solution space. I suspect that these two directions
>were conflated with each other in previous styles of process
>description, and that we may learn, thanks to XP, that processes can
>usefully vary along these two distinct dimensions.

Let's say you are in a startup that is making a router.
You have a small hardware, software, and marketing group.
What do you do now?

You just sit down and start coding?

Do you come up with a product requirements document?
Do you do some sort of analysis?
Do you research your competition?
Do you investigate existing stacks and OSs?
Do you try and size the amount of memory?
Do you come up with a real time budget?
Do you think about the processor?
Do you work with the hardware group? Do you even
have a hardware group until somebody has a story
that says put a packet over an interface?
Do you look at security issues and standards?

Do you actually think about the million things
you need to think about before even having a
real place to start?

I imagine you'll say all this stuff is
done by the customer, so it isn't the
concern of developers.

There are several problems with this answer.

Part of the cursed BFUD process is often
just this kind of creative work. Someone has to do it
and that someone is very often developers along
with marketing (etc) because marketing can't possibly
specify enough detail to create a router, for
example.

Often the developers in the project are domain
experts and are the ones with the most technical
capabilities to figure out what can be built.
Certainly at a high level this is negotiated
with marketing, but many times only the developers
can provide enough detail to provide meaningful
input into any planning game.

And if there isn't enough quality input it may
take a lot of work to figure out what needs to be
done. This work may feedback and change the higher
levels which may flow back down again as potentially
large changes elsewhere. It will be impossible to BFUD
the stories.

It seems stuff is still just getting throw over the
wall with no communication, it's just at the customer
level, not with the analysts or architects. It's BFUD
all over again, just at a different level.

I think a lot of confusion comes from how
restricted the role of the developer has become in
XP. Very often we developers have a lot more input and
responsibility for the entire system. In many industries
it would be rare to get fed enough detail that could be
used in a planning game. Developers often have responsibility
for creating that level of detail as well.

So it may end up looking a little BFUDy, but really
it's just reassociating developers with the part of that
process that XP has dissociated. You can't move complexity
to another group, decrease communication about the product,
and then declare victory. It's not really.

Jackson <spam@spam.com> wrote:

> ...
> So it may end up looking a little BFUDy, but really
> it's just reassociating developers with the part of that
> process that XP has dissociated. You can't move complexity
> to another group, decrease communication about the product,
> and then declare victory. It's not real[ity].

Hear here!

Elliott
--
Theory Leads, Practice Verifies

Profiteer US Out of Iraq Now!

"Jackson" <spam@spam.com> wrote in message
news:10kuhp4hn8n8d8f@news.supernews.com...
> This comment is an offshoot of the XP Requirement Analysis thread.
> 
>
> Let's say you are in a startup that is making a router.
> You have a small hardware, software, and marketing group.
> What do you do now?

Pick a development process that's suitable for a
combined hardware / software product that will
go into the retail market.

I'd probably start by looking at some flavor of
Lean Product Development.

Once I'd decided on that, then I'd look at what
process would be appropriate for the software
development sub-project.

John Roth

John Roth wrote:
> Once I'd decided on that, then I'd look at what
> process would be appropriate for the software
> development sub-project.

Any substantial software project has the same
issues.

The input into the planning game derives from
a BFUD process and is thrown over from the
customer to the developers in a way that
violates all the other principles of XP.

On Mon, 20 Sep 2004 14:12:47 -0700, Jackson <spam@spam.com> wrote:

>Let's say you are in a startup that is making a router.
>You have a small hardware, software, and marketing group.
>What do you do now?

Good!  Building conjoined hardware and software systems is something I
know a *lot* about.  I did it for nearly twenty years.
>
>You just sit down and start coding?

Code what?

>Do you come up with a product requirements document?

At least a product vision statement.  Something like: "This router is
for home use, it will handle DHCP, NAT, etc, etc, and should cost less
than $50.  The incoming pipe will be no faster than T1. etc. etc."

>Do you do some sort of analysis?

That depends on what you mean be analysis.  I think we want to do
enough to write that initial vision statement.

>Do you research your competition?

Yes, that would also be input into the vision statement.

>Do you investigate existing stacks and OSs?

Probably, though that needn't happen right away.  We could decide on
those things a bit later.  We could actually defer the OS decision for
several iterations, and the ISO stack could probably wait a while too.

>Do you try and size the amount of memory?

Memory is pretty cheap.  It seems obvious that we could fit it in a
single RAM chip.  The only variable is the size of the chip.  So we'll
be careful as we write the code, and we'll let everybody know how big
the code is getting.

>Do you come up with a real time budget?

Not until we understand the real-time structure of the system.  We
probably won't know that for several iterations.

>Do you think about the processor?

It'd be nice to know what the processor is.  I think we should pick
one that's fast and cheap.

>Do you work with the hardware group?

Sure.

>Do you even
>have a hardware group until somebody has a story
>that says put a packet over an interface?

Of course.  The hardware and software groups will work very closely
together.  At first the H/W team will be prototyping boards and
devices that the software team will be using.  Later they'll formalize
the hardware a bit more and get it ready for production.

>Do you look at security issues and standards?

Of course, though that can wait for awhile.  Let's get the initial
functionality working first.
>
>Do you actually think about the million things
>you need to think about before even having a
>real place to start?

We have a real place to start.  We can think about the million things
one at a time, in the order of their importance.
>
>I imagine you'll say all this stuff is
>done by the customer, so it isn't the
>concern of developers.

No it's the concern of the whole team.

>Part of the cursed BFUD process is often
>just this kind of creative work.

The creative work is fine.  Doing it all up front is a fools errand.

>Someone has to do it
>and that someone is very often developers along
>with marketing (etc) because marketing can't possibly
>specify enough detail to create a router, for
>example.

Granted.  I agree that the developers, (how & swab) must get deeply
involved with the specification.

>Often the developers in the project are domain
>experts and are the ones with the most technical
>capabilities to figure out what can be built.

True.

>Certainly at a high level this is negotiated
>with marketing, but many times only the developers
>can provide enough detail to provide meaningful
>input into any planning game.

True.

>And if there isn't enough quality input it may
>take a lot of work to figure out what needs to be
>done.

True.

>This work may feedback and change the higher
>levels which may flow back down again as potentially
>large changes elsewhere. It will be impossible to BFUD
>the stories.

True.

>It seems stuff is still just getting throw over the
>wall with no communication, it's just at the customer
>level, not with the analysts or architects. It's BFUD
>all over again, just at a different level.

I don't understand this statement.  I've worked on lots of projects
like this before.  You are right, the engineers always have
significant input to the requirements.  However, it's still one team,
working to deliver a product.
>
>I think a lot of confusion comes from how
>restricted the role of the developer has become in
>XP.

People can play more than one role.  There's no rule in XP that says
developers cannot also be part of the customer team.  Often they are.

>Very often we developers have a lot more input and
>responsibility for the entire system.

True.

>In many industries
>it would be rare to get fed enough detail that could be
>used in a planning game. Developers often have responsibility
>for creating that level of detail as well.

True.  But we can play multiple roles.

>So it may end up looking a little BFUDy, but really
>it's just reassociating developers with the part of that
>process that XP has dissociated.

I suppose you can look at it that way if you want.  XP sets up a
simple symmetry between the role of the developer and the role of the
customer.  This symmetry has to do with which role is responsible for
what.  Customers are responsible for specification, evaluating
business value, and scheduling stories into iterations.  Developers
are responsible for design, implementation, and estimation.  This
division is useful, but does not restrict the individuals themselves
from playing multiple roles.

>You can't move complexity
>to another group, decrease communication about the product,
>and then declare victory. It's not really.

Granted.  It's also not the XP way.


-----
Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.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

On Mon, 20 Sep 2004 16:14:14 -0700, Jackson <spam@spam.com> wrote:

>The input into the planning game derives from
>a BFUD process and is thrown over from the
>customer to the developers in a way that
>violates all the other principles of XP.

I'm not aware of anything in XP that precludes the customers having a
long list of things they want. Since the XP process begins with a
planning game Release Plan, where we consider all the available
stories (read "key use cases"), it's /good/ to have lots of features
on the want list.

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Robert C. Martin wrote:
 
>
> At least a product vision statement.  Something like: "This router is
> for home use, it will handle DHCP, NAT, etc, etc, and should cost less
> than $50.  The incoming pipe will be no faster than T1. etc. etc."

Note some of UB's line items have a number (50, 1, etc.).

There are those who insist on numbers (or binaries) for each line item, and
on a date for each line item, such as "we can bring the cost to less than
$50 per terabyte per day by the 1st Quarter of 2005".

The high-level tracking of the project now matches that vision statement.

> Probably, though that needn't happen right away.  We could decide on
> those things a bit later.  We could actually defer the OS decision for
> several iterations, and the ISO stack could probably wait a while too.

Right - picking an OS won't arbitrarily get those line items any closer.

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

Robert C. Martin wrote:
> Good!  Building conjoined hardware and software systems is something I
> know a *lot* about.  I did it for nearly twenty years.

From your comments that seems unlikely.

> 
> Code what?

Exactly.
 
>
> At least a product vision statement.  Something like: "This router is
> for home use, it will handle DHCP, NAT, etc, etc, and should cost less
> than $50.  The incoming pipe will be no faster than T1. etc. etc."

What do those things mean?
Will your security require a separate chip?
If not do we have the CPU and memory to implement
on the main CPU? Will i need special associative
memory for the routes? Do i need a timing plane?
These and 1000 other issues need to be resolved
before you start any planning game. They can't wait
for you to write some little bits of code that won't
matter a bit.
 
>
> That depends on what you mean be analysis.  I think we want to do
> enough to write that initial vision statement.

Your vision statement isn't even close enough to
make a useful start.
 
>
> Probably, though that needn't happen right away.  We could decide on
> those things a bit later.  We could actually defer the OS decision for
> several iterations, and the ISO stack could probably wait a while too.

I guess you won't worry about those real-time
or reliability or 3rd party software issues until
when? How would you know what to build or buy
until you did enough thinking to know what you
need and if it is availble for your OS and your
chip set and has acceptable licensing terms? Are their
drivers for your hardware? How would you know
if you can meet your performance requirements? You
might want to acutally think about that
because it has everything to do with all the
stuff you aren't thinking about until later.
 
>
> Memory is pretty cheap.  It seems obvious that we could fit it in a
> single RAM chip.  The only variable is the size of the chip.  So we'll
> be careful as we write the code, and we'll let everybody know how big
> the code is getting.

Are you joking?
Your product cost is $50 and you are saying memory is cheap?
I think hardware might want to know the eprom size. They
might want to know the power for the board and how much
space they need to leave available. Your "etc etc" in the vision
statement could be quite surprising.
 
>
> It'd be nice to know what the processor is.  I think we should pick
> one that's fast and cheap.

Hardware may actually need to know this about a second after
you make your vision statement. You won't be able to change later.
How fast? Based on what? How cheap? Should have multiple CPUs?
A multicore CPU? Will your OS support that? Or do you need
specialized chips, an ASIC, or a network processor instead?

> Of course.  The hardware and software groups will work very closely
> together.  At first the H/W team will be prototyping boards and
> devices that the software team will be using.

If you run your first iterations on anything from the hardware
group i'll eat your hat. You'll be using an emulation system
for quite some time.

> Of course, though that can wait for awhile.  Let's get the initial
> functionality working first.

That is the initial functionality of any system. Jeesh. And
in a thing that has 1000 parts, what can be considered initial?

> We have a real place to start.

Where is that? I missed it.
 
>
> The creative work is fine.  Doing it all up front is a fools errand.

Who said to do that? If i should disagree with your clearly
inadequate approach i am a fool? Nice.

Jackson,
 
>
>  From your comments that seems unlikely.

On the Internet, nobody knows you're a dog...

Could we agree to assume that people are whoever they say they are, and
have whatever experience they claim, as one of the ground rules of this
conversation ? I'm not interested in engaging unless that rule prevails.

Laurent
http://bossavit.com/thoughts/

Jackson,
 
>
> hardware may actually need to know this about a second after
> you make your vision statement. You won't be able to change later.
> [...]
> You'll be using an emulation system for quite some time.

If we're going to be using emulation for a while, why does the hardware
group need to know about the processor so early, and why does that
commitment have to be so firm that we can't change our minds later ?

Laurent
http://bossavit.com/thoughts/