Home > Archive > Extreme Programming > September 2004 > So let's build a router
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
So let's build a router
|
|
| Jackson 2004-09-20, 8:59 pm |
| 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.
| |
| Universe 2004-09-20, 8:59 pm |
| 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!
| |
| John Roth 2004-09-20, 8:59 pm |
|
"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
| |
| Jackson 2004-09-20, 8:59 pm |
|
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.
| |
| Robert C. Martin 2004-09-20, 8:59 pm |
| 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
| |
| Ronald E Jeffries 2004-09-21, 3:57 am |
| 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
| |
| Jackson 2004-09-21, 3:57 am |
|
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.
| |
| Steve Jorgensen 2004-09-21, 3:57 am |
| On Mon, 20 Sep 2004 20:20:52 -0400, Universe <universe@tAkEcovad.OuT.net>
wrote:
>Robert C. Martin <unclebob@objectmentor.com> wrote:
>
>
>
>This is daft.
Back here in your usual mode, I see.
>The developers should primarily determine what goes into what iteration
>based upon a system architectural plan that at least minimally covers
>all key architectural aspects. The architectural plan should be
>determimed by project domain and use case investigation - analysis -
>that at least covers all key use cases.
That's an assertion. What's your argument for the assertion? Personally, my
evolution in programming has been from a design-as-you-go with no process that
didn't work to a BUFD process that didn't work to a design-as-you-go process
(namely XP) that seems to be working pretty well. I'm not saying it's the
only right answer, but I can tell you why I think it's a good answer - I've
tried it, and I like the results.
>Any out of Programming 101 knows the technical people should create the
>major goals of, especially early iterations. This in order to lay the
>best technical basis for system development that most efficiently,
>economically and rationally lays the basis for overall development of
>the system.
OK, forgetting the implied, baseless insult to anyone who disagrees with
you...
I think what's obvious is that the customer needs to define the major goals
because that's who is in charge of trying to sell something or meet the
requirements of some market, user segment, or other business need. The
feedback from the "technical people" on how long it will take and how much it
will cost to do the things the customer would like should have a big impact on
what the customer decides to pay for, but it is the customer that decides.
As one of the "technical people", I know you shouldn't leave it to me, because
I'll pick what's most fun and challenging to implement, not what's the most
valuable use of my time (not on purpose, you understand).
| |
| Laurent Bossavit 2004-09-21, 3:57 am |
| 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/
| |
| Laurent Bossavit 2004-09-21, 3:57 am |
| 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/
| |
| Laurent Bossavit 2004-09-21, 9:00 am |
| Jackson,
Thanks for a provocative statement.
This discussion is at risk of confusion because the term "process" is
terribly overloaded and fails to distinguish between several different
aspects.
In the comment from which the current thread was spawned, the aspect of
"process" to which I was referring was the "when" question: when do the
various activities in a creative problem-solving effort take place?
Among these actitivies we find "problem space exploration", i.e.
requirements, "solution space exploration", i.e. analysis, and "solution
implementation", i.e. coding. Cognitive style plays a role in answering
"when", in particular in choosing whether to do a lot of exploration in
advance of implementation, or whether to have these activities
overlapping to a large extent.
You're also asking about "who" questions: who does what ? That's a
separate aspect of "process", but one in which cognitive style also
matters a lot.
> Let's say you are in a startup that is making a router.
> You have a small hardware, software, and marketing group.
Entrepreneurial experience suggests that getting to that point is a lot
of work - summing all that up in two lines may give the impression of a
"blank slate" at that point, which is extremely unlikely to be the case.
> What do you do now?
Accordingly, the first thing I'd want to do is to take stock of the
direction that this firm is /already/ moving in. This is likely to have
been primarily an exploration in problem space: identifying a niche of
the overall market in which it is possible to compete, listing the main
competitors in that niche and their major selling points, figuring out
in rough terms the break-even sales volume and other hypotheses,
locating the industrial capability to mass-produce the device, etc.
Is there "big picture" thinking in all this ? Probably, although I
suspect that entrepreneurs are just as variable as authors: some of them
will get the plan down to dozens of spreadsheets detailing every
projected expense and outcome to the exact cent, others will just follow
their instinct, sometimes in "scratch an itch" fashion - as I recall,
there are a number of open source projects out there with no more of an
initial plan than "so let's build a router".
But if there has been "big picture" thinking, it has probably been
mostly in the problem space, not in the solution space.
> You just sit down and start coding?
To simplify, assume this is the first day of operation of the startup.
Everyone in the group, from now on, is /consuming/ resources - and if
we're a typical startup, our survival depends on how fast we establish
that we can /generate/ appropriate amounts of cash - through sales or
otherwise.
The question is, can we afford not to start coding ? Or if not coding,
per se, then at least some increment of the solution that gives us some
sort of feedback on when we are going to stop losing money.
It helps if we're not building the whole thing at once - say, we might
be starting by rewriting the firmware for a device that already exists.
In which case we know plenty about the constraints on our work, and we
probably know enough to elicit user stories and enter the planning game.
Simultaneously we could start "cloning" that existing device, replacing
it by one of our own design, striving to remain compatible with the
software. Is that a plausible scenario at all ?
It could be that all I'm illustrating here is a distinction between a
"blank slate" approach to the business strategy and an "evolutionary"
one. And it could well be that more up-front, "big picture" work is
required in a blank slate approach than in an evolutionary one. In which
case we, as entrepreneurs, can choose which approach best fits the
cognitive style we favor.
> 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.
Perhaps this is because we have picked a domain that is eminently
technical ? We might still want to separate the responsibilities by
hiring a very technical person as the product manager and having that
person have a final say on problem-space issues.
This doesn't imply that developers have to be unaware of the domain, or
that they are prohibited from contributing to the initial pool of user
stories, or that their input on problem-space is totally discounted; it
certainly doesn't imply that customers don't value their solution-space
expertise.
Laurent
http://bossavit.com/thoughts/
| |
| Robert C. Martin 2004-09-21, 3:57 pm |
| On Tue, 21 Sep 2004 06:47:23 GMT, Steve Jorgensen
<nospam@nospam.nospam> wrote:
>I think what's obvious is that the customer needs to define the major goals
>because that's who is in charge of trying to sell something or meet the
>requirements of some market, user segment, or other business need.
One of the OP's (Jackson's) original points is valid, however. In a
highly technical marketplace the developers often know more about what
the product should be than the marketing people. (This is a shame,
but it is also reality.) In such environments the developers will
play a significant part of the customer role.
-----
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
| |
| Robert C. Martin 2004-09-21, 3:57 pm |
| On Mon, 20 Sep 2004 21:47:15 -0700, Jackson <spam@spam.com> wrote:
>
>Robert C. Martin wrote:
>
> From your comments that seems unlikely.
I guess our conversation is over.
-----
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
| |
| Robert C. Martin 2004-09-21, 3:57 pm |
| On Mon, 20 Sep 2004 21:47:15 -0700, Jackson <spam@spam.com> wrote:
>
>Who said to do that? If i should disagree with your clearly
>inadequate approach i am a fool? Nice.
Perhaps it was my "fools errand" statement that provoked you to imply
that I was lying about my experience. The term "fool's errand" is a
common idiom (search on google to see how common) meaning "a waste of
effort". I was not calling you a fool. However I can see how you
might have taken offense if you were unfamiliar with the idiom.
As for my experience, I have been a software professional for over
thirty five years. I worked in the telecommunications industry for
over twenty of those. I was a software developer, project lead,
primary architect, and engineering manager on devices like protocol
converters, statistical multiplexors, voice mail/voice response
systems, telephone test equipment, etc, etc. In short I have a long
and successful history of shipping embedded real-time
telecommunications devices to a hungry market.
I have done both highly disciplined up-front document-driven
development, and highly disciplined incremental development. I have
been successful with both, but prefer the latter. I have found that
people steeped in the former often think that the latter is infeasible
or impractical. My experience contradicts that.
-----
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
| |
| Universe 2004-09-21, 3:57 pm |
| Robert C. Martin <unclebob@objectmentor.com> wrote:
> On Mon, 20 Sep 2004 21:47:15 -0700, Jackson <spam@spam.com> wrote:
[color=darkred]
[color=darkred]
> I guess our conversation is over.
Nawww!
Can't be. Hahahahahaha....! :- }
Elliott
--
*[Confabulation - spurious memories or fabrications are very common in
psychiatric disorders and may take on an expansive and grandiose
character. They may also embody obvious elements from fantasy and
dream.]
--
Segregating the wheat from the chafe principle!
| |
| Ronald E Jeffries 2004-09-21, 3:57 pm |
| On Mon, 20 Sep 2004 20:20:52 -0400, Universe
<universe@tAkEcovad.OuT.net> wrote:
>Any out of Programming 101 knows the technical people should create the
>major goals of, especially early iterations. This in order to lay the
>best technical basis for system development that most efficiently,
>economically and rationally lays the basis for overall development of
>the system.
When you get to Programming 201, they'll cover other ways of building
software that many of us have learned and found quite valuable. 101's
a good course, but it's not the last course. Neither is 201. There's
still much learning to be had.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Universe 2004-09-21, 3:57 pm |
| Ronald E Jeffries <ronjeffries@acm.org> wrote:
> On Mon, 20 Sep 2004 20:20:52 -0400, Universe
> <universe@tAkEcovad.OuT.net> wrote:
>
>
> When you get to Programming 201, they'll cover other ways of building
> software that many of us have learned and found quite valuable. 101's
> a good course, but it's not the last course. Neither is 201. There's
> still much learning to be had.
>
> Regards,
And your off-topic point was regarding my concrete, detailed reasons:[color=darkred]
is.....???
M.O. XP backed to a corner:
No concrete, on topic response to my concrete point, just, more feel
good for *them* "grandiloquent" ;- } posturing.
Hahahahahaha....!
Elliott
--
Theory Leads, Practice Verifies
Profiteer US Out of Iraq Now!
| |
| Universe 2004-09-21, 8:56 pm |
| Ronald E Jeffries <ronjeffries@acm.org> wrote:
> On Mon, 20 Sep 2004 16:14:14 -0700, Jackson <spam@spam.com> wrote:
>
>
> 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.
Before diving right into a release plan how about having a firm basis
upon which to base a release plan?
That imo means doing at least minimal overall analysis of at least all
key elements related to:
` project scope relevant domain entities and affairs
` project scope relevant use case entities and affairs
Doing at least minimal overall analysis of all of at least key means:
~ at least minimal overall investigation of any current related
cybernetic systems
~ at least minimal overall current input appraisal
~ at least minimal overall current output appraisal
~ at least minimal overall interviews of users
~ at least minimal overall interviews of domain experts
~ at least minimal overall prototype verification of initially given
use cases (user stories)
~ at least minimal overall elicitation and specification of
additional
Elliott
--
Global Plans + Iterative/Incremental Implementation
Theory Leads, Practice Verifies
| |
| Universe 2004-09-21, 8:56 pm |
| Robert C. Martin <unclebob@objectmentor.com> wrote:
> On Mon, 20 Sep 2004 21:47:15 -0700, Jackson <spam@spam.com> wrote:
>
>
> Perhaps it was my "fools errand" statement that provoked you to imply
> that I was lying about my experience. The term "fool's errand" is a
> common idiom (search on google to see how common) meaning "a waste of
> effort". I was not calling you a fool. However I can see how you
> might have taken offense if you were unfamiliar with the idiom.
"Might", no kiddin'?
> As for my experience, I have been a software professional for over
> thirty five years. I worked in the telecommunications industry for
> over twenty of those. I was a software developer, project lead,
> primary architect, and engineering manager on devices like protocol
> converters, statistical multiplexors, voice mail/voice response
> systems, telephone test equipment, etc, etc. In short I have a long
> and successful history of shipping embedded real-time
> telecommunications devices to a hungry market.
Doing the wrong year, after year, over and over is especially a "fools
errand".
You don't offense at that do 'ya?
> I have done both highly disciplined up-front document-driven
> development, and highly disciplined incremental development.
RCM's unscientific approach is evident. What the heck is "document
driven development". He's such a hardcore hacker.
The mainstream combines conceptual modelling led development - be it
recorded on hardcopy, electronically, or some combo of both - WITH IID-
iterative/incremental development.
The hacker RCM hasn't a clue how the 2 opposites are combined in a
software engineering dialectic development delight. 'Tis truly
"delovely" when are a theory led, practice verified computer scientist.
> I have
> been successful with both, but prefer the latter. I have found that
> people steeped in the former often think that the latter is infeasible
> or impractical. My experience contradicts that.
Those "steamin'" in it, don't see the steeped for the stupid.
Elliott
--
Theory Leads, Practice Verifies
Profiteer US Out of Iraq Now!
| |
| Universe 2004-09-21, 8:56 pm |
| Robert C. Martin <unclebob@objectmentor.com> wrote:
> On Tue, 21 Sep 2004 06:47:23 GMT, Steve Jorgensen
> <nospam@nospam.nospam> wrote:
>
[color=darkred]
> One of the OP's (Jackson's) original points is valid, however. In a
> highly technical marketplace the developers often know more about what
> the product should be than the marketing people. (This is a shame,
> but it is also reality.) In such environments the developers will
> play a significant part of the customer role.
>
What a prima donna crock, "play a significant part of the customer
role.".
What the.... does that mean?!
Earlier I said the developers should have a major say on what the nature
of early release are like based upon their understanding of how features
relate to architecture. There is a need to initialize the system
architecture in way that the whole project is done economically and
efficiently.
But of course that is done via discussion with the client about what
their early needs are in terms of use cases.
That is a scientific, systems oriented approach, versus the prima donna
hackerism evidenced above by RMartin.
Elliott
--
Theory Leads, Practice Verifies
Profiteer US Out of Iraq Now!
| |
| Steve Jorgensen 2004-09-22, 3:56 am |
| On Tue, 21 Sep 2004 15:47:23 -0400, Universe <universe@tAkEcovad.OuT.net>
wrote:
>Ronald E Jeffries <ronjeffries@acm.org> wrote:
>
>
>
>And your off-topic point was regarding my concrete, detailed reasons:
>is.....???
>
>M.O. XP backed to a corner:
> No concrete, on topic response to my concrete point, just, more feel
>good for *them* "grandiloquent" ;- } posturing.
>
>Hahahahahaha....!
>
>Elliott
Now, it's clear you're jsut trollng. You made no concrete point, just
baseless assertions and insulting inuendos. now, you accuse your responders
of having no concrete response. I see it's a mistake to bother to read your
posts or respond.
| |
| Ronald E Jeffries 2004-09-22, 3:56 am |
| On Tue, 21 Sep 2004 16:09:46 -0400, Universe
<universe@tAkEcovad.OuT.net> wrote:
>Before diving right into a release plan how about having a firm basis
>upon which to base a release plan?
>
>That imo means doing at least minimal overall analysis of at least all
>key elements related to:
> ` project scope relevant domain entities and affairs
> ` project scope relevant use case entities and affairs
>
>Doing at least minimal overall analysis of all of at least key means:
> ~ at least minimal overall investigation of any current related
> cybernetic systems
> ~ at least minimal overall current input appraisal
> ~ at least minimal overall current output appraisal
> ~ at least minimal overall interviews of users
> ~ at least minimal overall interviews of domain experts
> ~ at least minimal overall prototype verification of initially given
> use cases (user stories)
> ~ at least minimal overall elicitation and specification of
> additional
Well, since a Release Plan is an Extreme Programming thing, I feel
confident in assuring the readership that the above is NOT how one
does it.
We can think of the purpose of XP (and Agile methods) as getting as
quickly as possible to delivering valuable features, in
customer-specified order, while sustaining high quality and consistent
speed of implementation. It's no longer interesting to debate whether
we can do this, because people all over the world are doing it.
Interested parties might wish to discuss /how/ we do it, or /why/ it
works. I'd love to help with that.
The Release Plan is the part of the planning process that looks at the
larger picture, from today until the next release of the software.
This is in contrast to the Iteration Plan, which is a detailed plan of
the next couple of w s' work.
In the Release Planning process, we look at the individual features
(stories, they are called in XP), and break them down until they are
all about the same size. Today's teams are breaking them down as small
as two or three days' work by a single pair of programmers; in earlier
days we let them be larger, up to a couple of ws' work.
Any reasonable size project of course has a large number of such
stories, and with a narrow range of estimated size, the law of large
numbers works in our favor. The standard deviation of a sum of random
variables is much smaller than the standard deviation of the
individual samples. So as soon as we know the /mean/ of how long it
will take us to do stories, we have a good estimate of how long the
project will take. We can estimate the mean, but the best way is of
course to measure it, by doing stories and seeing how long it takes.
The result of doing this simple planning exercise -- which might take
a w at the beginning of a 10 person-year project, and more like a
day after the first time -- is that we are in a position to project
more and more accurately how long things will take.
Combine that with the practices of
- delivering a fully integrated running system to the "customer" every
couple of ws;
- using comprehensive customer and programmer tests to ensure that
features implemented work, and stay working;
- measuring progress in terms of features completed rather than less
tangible notions such as what percentage of the design is done;
- evolving the design /with/ the implementation rather than beforehand
(leads to over-investment) or later (leads to boggng down) keeps
feature implementation velocity approximately constant.
The result is a software project that measurably produces running
tested software at a regular pace.
The Release Plan is the overview planning part of that process.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Universe 2004-09-22, 3:56 am |
| Ahhhhhhh!!!
Steve Jorgensen <nospam@nospam.nospam> wrote:
> On Tue, 21 Sep 2004 15:47:23 -0400, Universe <universe@tAkEcovad.OuT.net>
> wrote:
>
>
> Now, it's clear you're jsut trollng. You made no concrete point, just
> baseless assertions and insulting inuendos. now, you accuse your responders
> of having no concrete response. I see it's a mistake to bother to read your
> posts or respond.
--
Theory Leads, Practice Verifies
Profiteer US Out of Iraq Now!
| |
| Universe 2004-09-22, 3:56 am |
| Ronald E Jeffries <ronjeffries@acm.org> wrote:
> On Tue, 21 Sep 2004 16:09:46 -0400, Universe
> <universe@tAkEcovad.OuT.net> wrote:
>
>
> Well, since a Release Plan is an Extreme Programming thing, I feel
> confident in assuring the readership that the above is NOT how one
> does it.
You're out of your gourd. Read Booch, Rumbaugh, Jacobson and just any
well known OO engineer from the *1980's* and you'll see the term,
"Release Plan".
You XP'ers are pip you know that, an OO and SW Engineering methods
uninformed pip.
Elliott
--
Confabulation - spurious memories or fabrications are very common in
psychiatric disorders and may take on an expansive and grandiose
character. They may also embody obvious elements from fantasy and
dream.
| |
| Laurent Bossavit 2004-09-22, 3:56 am |
| Elliott,
> ~ at least minimal overall interviews of users
I'm having trouble visualizing what an "at least minimal overall
interview" might possibly be.
If I have one chat with someone who has used a router, will that be
enough ? Does it need to be a structured interview ? Does she need to be
a user who has been aware of using the router ? If one isn't sufficient,
how many are sufficient ? What information does the interview need to
elicit ?
Laurent
http://bossavit.com/thoughts/
| |
| Ronald E Jeffries 2004-09-22, 9:07 am |
| On Tue, 21 Sep 2004 23:08:08 -0400, Universe
<universe@tAkEcovad.OuT.net> wrote:
>You're out of your gourd. Read Booch, Rumbaugh, Jacobson and just any
>well known OO engineer from the *1980's* and you'll see the term,
>"Release Plan".
Well, I just looked in the indices of Grady's OOD and Ivar's OOSE, and
I do not find the phrase "Release Plan". Perhaps you could provide a
more direct reference.
And in this thread, I introduced the term "Release Plan", so I am
fairly confident that the XP term was meant in this case.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Universe 2004-09-22, 9:07 am |
| Ronald E Jeffries <ronjeffries@acm.org> wrote:
> On Tue, 21 Sep 2004 23:08:08 -0400, Universe
> <universe@tAkEcovad.OuT.net> wrote:
>
>
> Well, I just looked in the indices of Grady's OOD and Ivar's OOSE, and
> I do not find the phrase "Release Plan". Perhaps you could provide a
> more direct reference.
>
> And in this thread, I introduced the term "Release Plan", so I am
> fairly confident that the XP term was meant in this case.
You weren't looking hard enuff.
Plus, great logic <not>. You said it 1st in this thread so we are
beholden to the half-a-nickel, "flickted" way XP'ers see it.
Elliott
--
Theory Leads, Practice Verifies
Profiteer US Out of Iraq Now!
| |
| Universe 2004-09-22, 9:07 am |
| Steve Jorgensen <nospam@nospam.nospam> wrote:
> On Tue, 21 Sep 2004 15:47:23 -0400, Universe <universe@tAkEcovad.OuT.net>
> wrote:
>
>
> Now, it's clear you're jsut trollng. You made no concrete point, just
> baseless assertions and insulting inuendos. now, you accuse your responders
> of having no concrete response. I see it's a mistake to bother to read your
> posts or respond.
You're wrong. Reread. This was my concrete point:[color=darkred]
that there still is no concrete XP answer to.
Elliott
--
Theory Leads, Practice Verifies
Profiteer US Out of Iraq Now!
| |
| Universe 2004-09-22, 3:58 pm |
| X-Newsreader: Forte Agent 2.0/32.652
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 34
NNTP-Posting-Host: 216.251.47.166
X-Trace: 1095858134 reader1.on.meganewsservers.com 1313 216.251.47.166:34964
Xref: number1.nntp.dca.giganews.com comp.object:181876 comp.software.extreme-programming:30773
Laurent Bossavit <laurent@dontspambossavit.com> wrote:
> Elliott,
>
>
> I'm having trouble visualizing what an "at least minimal overall
> interview" might possibly be.
Just parse each word slowly and use your imagination a bit more.
OK, here's a reformulation:
Overall, but minimal.
N'est ce pas?
Elliott
> If I have one chat with someone who has used a router, will that be
> enough ? Does it need to be a structured interview ? Does she need to be
> a user who has been aware of using the router ? If one isn't sufficient,
> how many are sufficient ? What information does the interview need to
> elicit ?
That is all the stuff that needs to be context analyzed, that XP
forgoes by hacker diving right in without it.
Elliott
--
Theory Leads, Practice Verifies
Profiteer US Out of Iraq Now!
| |
| Laurent Bossavit 2004-09-22, 3:58 pm |
| Elliott,
> That is all the stuff that needs to be context analyzed,
In the present instance we have a context (building a router). Based on
that context, what concrete answers to my questions would you recommend?
What kind of interviewing, and how much, is required in that context ?
If the context hasn't been specified in enough detail, what further
aspects of the context would you look at to decide how much, and what
kind of, interviewing is appropriate ?
Laurent
http://bossavit.com/thoughts/
| |
| Steve Jorgensen 2004-09-22, 3:58 pm |
| On Wed, 22 Sep 2004 08:58:42 -0400, Universe <universe@tAkEcovad.OuT.net>
wrote:
>Steve Jorgensen <nospam@nospam.nospam> wrote:
>
>
>You're wrong. Reread. This was my concrete point:
>that there still is no concrete XP answer to.
>
>Elliott
Well, I guess I'm somewhat sorry then. I thought you were trying to say that
you made some concrete point in your essage that says "This is daft." and "Any
out of Programming 101 knows..."
With regard to a combined software/hardware project, I have no direct
experience, so I will not claim to have a basis to participate. You might
keep in mind though that the person who uses personal attacks and belittling
language prior to trying to make any logical arguments in their discussions is
usually the one I assume to be wrong.
| |
|
| Steve Jorgensen wrote:
> With regard to a combined software/hardware project, I have no direct
> experience, so I will not claim to have a basis to participate.
I have experience writing supplements to hardware controllers.
For one project, I wrote an emulator that pretended it was a controller, and
it communicated over the serial port. Then I put a loopback cable on my
computer, and ran our data collection program in another session. Adding
features consisted of implementing them in the emulator, running it, and
making the data collection program match them.
I now recognize the velocity boost I got as TDD...
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Universe 2004-09-22, 3:58 pm |
| Steve Jorgensen <nospam@nospam.nospam> wrote:
Universe wrote:
[color=darkred]
> Well, I guess I'm somewhat sorry then. I thought you were trying to say that
> you made some concrete point in your essage that says "This is daft." and "Any
> out of Programming 101 knows..."
>
> With regard to a combined software/hardware project, I have no direct
> experience, so I will not claim to have a basis to participate. You might
> keep in mind though that the person who uses personal attacks and belittling
> language prior to trying to make any logical arguments in their discussions is
> usually the one I assume to be wrong.
Weigh a person's total output both in the group and within a thread.
I think you'll find the scales tip heavily in favor of concrete,
substance on my part.
Elliott
--
Theory Leads, Practice Verifies
Profiteer US Out of Iraq Now!
| |
| Universe 2004-09-22, 8:58 pm |
| Laurent Bossavit <laurent@dontspambossavit.com> wrote:
> Elliott,
>
>
> In the present instance we have a context (building a router). Based on
> that context, what concrete answers to my questions would you recommend?
> What kind of interviewing, and how much, is required in that context ?
>
> If the context hasn't been specified in enough detail, what further
> aspects of the context would you look at to decide how much, and what
> kind of, interviewing is appropriate ?
How far do you see us going with this? More importantly why should we
collaborate to create a router? What are your aims?
Elliott
--
"'Business priority' in the absence of considering the
synergies/dependencies between features is meaningless. Prioritizing
a list that you haven't fully reseached and assembled
is simply creating an illusion of rigour." ~ Cy Coe
| |
| Universe 2004-09-26, 3:55 am |
| Xref: number1.nntp.dca.giganews.com comp.object:182048 comp.software.extreme-programming:30838
Laurent Bossavit <laurent@dontspambossavit.com> wrote:
> Elliott,
>
>
> In the present instance we have a context (building a router). Based on
> that context, what concrete answers to my questions would you recommend?
> What kind of interviewing, and how much, is required in that context ?
>
> If the context hasn't been specified in enough detail, what further
> aspects of the context would you look at to decide how much, and what
> kind of, interviewing is appropriate ?
How far do you see us going with this? More importantly why should we
collaborate to create a router? What are your aims?
Elliott
Mainstream OO developers find that discovering and
implementing objective domain abstractions as the core
of high level design is optimal for system architecture
in virtually every aspect - time, effort, complexity
reduction, complexity management,intuitiveness,
preparation for future up scaling, flexibility when
modifying the software due to changes in the domain.
Many of the benefits result from major units of abstraction
in the high level software architecture being aligned
and corresponding with those in the domain.
There is an ease in implementing use cases as flowing
around and through the same abstractions in software as
they do for business processes. Also the potential for
reusability of abstractions and relationships is maximized,
etc and so on, ad infinitum.
|
|
|
|
|