Re: So let's build a router

From: Robert C. Martin (unclebob_at_objectmentor.com)
Date: 09/21/04 

Date: Mon, 20 Sep 2004 18:55:17 -0500

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

Relevant Pages

  • Re: Why is OO popular?
    ... What the customers initially think they want is sometimes ... > software developers? ... >>new technology and then depending on Marketing to convince the customers ... >>software developer responsibility. ...
    (comp.object)
  • Re: Story Time
    ... The only thing Linux has that BSD ... The GPL attracted a lot of people to the Linux platform. ... And the answer is, marketing. ... As developers become interested in the platform, ...
    (comp.os.vms)
  • Re: NetworkManager update
    ... I see you do indeed seem to be operating hardware that requires interaction of a number of different, independently developed, bleeding edge bits--ndiswrapper and the closed-source driver for your card, the open-source driver for your card, NetworkManager, etc. ... Well, understanding that about yourself, you can understand how developers can get into the same mindset. ... But to effectively work with a diverse group of specialists such as the driver authors and the ndiswrapper authors and the NM and wpa_supplicant authors, you will need to get out of that mindset yourself and be disciplined about gathering evidence and working your way through the process and encourage the developers you are working with to get out of their mindset and communicate with you enough so that you reach common understanding. ...
    (Fedora)
  • Re: Bitwise OR just like SUM or COUNT
    ... > until the 1960's the cost of the hardware was ten times OR MORE the cost ... were doomed from the get-go because of a lack of resources (cash, hardware, ... etc. I've known many smart developers that worked for large ... for the database ...
    (microsoft.public.sqlserver.programming)
  • Re: Why We Use C Than C++...
    ... functions to handle hardware interrupts and C is the most portable language for doing this. ... templates and the practice of using classes in the place of primitives, to name two examples, cause unacceptable code bloat. ... An experienced team of C developers will produce a much better result than an inexperienced team of C++ developers. ...
    (comp.lang.c)