Home > Archive > Extreme Programming > September 2004 > What is Business Value? (slight return)
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 |
What is Business Value? (slight return)
|
|
| Scott Kinney 2004-09-27, 9:00 pm |
| I think this deserves its own thread, so I've
reposted it out of the 'Estimating' thread with
additional comments....
"Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
news:cj7gal$mqk$1@news.freedom2surf.net...
> Corey Burnett wrote:
>
news:<10lbmlna1r6lb41@news.supernews.com>...[color=darkred]
>
> What is business value?
>
> We tend to think its fully working, fully developed systems meeting all
> of the critical requirements...
>
From the customer's point of view, business value is more
about how completely they can do their work in the new
application.
>
> By implementing small sub-parts of the critical requirements in dribs
> and drabs, with each passing iteration. The customers get to see REAL
> working applications that meet those small sub-part requirements.
>
They get to see them, but they may not be able to use them. The above
example; we installed a working login module, of course, it doesn't connect
to anything.... is a good example.
Philip, when business value comes up, usually characterizes it as
'improving customer productivity', and the amount of value is the
amount by which productivity improves.
If software is 'testable but not releasable',
then at best, it has no impact on customer productivity, at worst,
it reduces productivity to the extent that customers are expected to
break from their work to test the software.
If the software released doesn't allow the customer to do complete
transactions or business processes, then it reduces productivity to the
extent that customers must do duplicate work.
(This was my experience
in a project that did iterative releases of functions. The goal of the
project
was to replace 2 separate case management applications with 1 case
management
application, implement functions pertaining to HIPAA regs, and respond to
new state audit requirements.) Until the functionality achieved a certain
critical mass (enough to eliminate 1 application, for example), what was
data entry into 2 systems became data entry into 3 systems.
While I wouldn't call the XP claim to 'deliver business value with each
iteration'
an illusion, I do think the claim needs something more in the way of
concrete evidence.
(An interesting footnote; in the books I've read so far on
agile methods and XP, none of the examples of release planning
given would meet Philip's test of improving customer productivity.
They were more in line with Corey's point, delivery of admittedly
working software too limited to be of actual use.)
| |
| George 2004-09-28, 3:59 am |
|
Scott Kinney wrote:
> They get to see them, but they may not be able to use them. The above
> example; we installed a working login module, of course, it doesn't connect
> to anything.... is a good example.
I was wondering in the login example, if 5 people worked
on a feature and all of them needed to login first, and
the login hadn't been done yet because it is not
an end-to-end story itself, would all 5 developers create
their own login system to get there story implemented?
I think there is room for dependency based horizontal
features.
| |
| Ronald E Jeffries 2004-09-28, 3:59 am |
| On Mon, 27 Sep 2004 19:50:48 -0700, George <somewhere@nowhere.com>
wrote:
>
>I was wondering in the login example, if 5 people worked
>on a feature and all of them needed to login first, and
>the login hadn't been done yet because it is not
>an end-to-end story itself, would all 5 developers create
>their own login system to get there story implemented?
>I think there is room for dependency based horizontal
>features.
Yes, but the team will figure that out on the fly unless they are as
dumb as frogs and never talk to each other. And if they are like that,
they should be doing some other process, since they're doomed and we
want to keep our average up. :)
But seriously, folks, the dependencies aren't what we think they are,
they are often much easier to deal with than we fear, and the team can
and should sort them out as they go.
--
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 2004-09-28, 3:59 am |
| On Mon, 27 Sep 2004 19:50:48 -0700, George <somewhere@nowhere.com>
wrote:
>
>
>Scott Kinney wrote:
>
>I was wondering in the login example, if 5 people worked
>on a feature and all of them needed to login first, and
>the login hadn't been done yet because it is not
>an end-to-end story itself, would all 5 developers create
>their own login system to get there story implemented?
No, each one would stub out the login process.
>I think there is room for dependency based horizontal
>features.
There probably is, but the more we can creatively avoid dependencies
the more flexibility we have to deliver business value.
-----
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
| |
| George 2004-09-28, 3:59 am |
|
Ronald E Jeffries wrote:
> Yes, but the team will figure that out on the fly unless they are as
> dumb as frogs and never talk to each other.
I guess robert thinks they eat flies then :-)
Though i am not sure why they would figure it out on
the fly or why that is better than just recongnizing the
obvious, that we need to do the login. Loging in, especially
in a servlet/jsp environment is not at all simple and does require
some thought and research.
> But seriously, folks, the dependencies aren't what we think they are,
> they are often much easier to deal with than we fear, and the team can
> and should sort them out as they go.
I am not sure what that all means. In this case the dependency is quite
clear and obvious so i'll risk saying it is what we think it is.
I don't fear them in any scenario.
| |
| Ilja Preuß 2004-09-28, 3:59 am |
| George wrote:
> Ronald E Jeffries wrote:
>
> Though i am not sure why they would figure it out on
> the fly
Because they discuss what they will do in the morning (Stand Up Meeting),
all work in the same room and pair program with a different partner every
few hours?
> or why that is better than just recongnizing the
> obvious, that we need to do the login.
Because it isn't obvious - you just think it is. Seriously.
> Loging in, especially
> in a servlet/jsp environment is not at all simple and does require
> some thought and research.
And that's exactly why we should defer the effort until we really need it.
>
> I am not sure what that all means. In this case the dependency is
> quite clear and obvious so i'll risk saying it is what we think it is.
Well, we did exactly that: wrote a web frontend for an
until-then-swing-application that needed users to login and deferred the
implementation of the login until w s after the first deployment.
Cheers, Ilja
| |
| Ronald E Jeffries 2004-09-28, 9:02 am |
| On Mon, 27 Sep 2004 21:27:42 -0700, George <somewhere@nowhere.com>
wrote:
>Ronald E Jeffries wrote:
>
>I guess robert thinks they eat flies then :-)
Yum.
>
>Though i am not sure why they would figure it out on
>the fly or why that is better than just recongnizing the
>obvious, that we need to do the login. Loging in, especially
>in a servlet/jsp environment is not at all simple and does require
>some thought and research.
If it's obvious, then certainly it'll be recognized. In this case, as
I'll mention below, I suspect there's no dependency at all, or not
much of one.
>
>
>
>I am not sure what that all means. In this case the dependency is quite
>clear and obvious so i'll risk saying it is what we think it is.
>I don't fear them in any scenario.
I don't fear them either, because I've learned there aren't as many as
I thought.
For example, what makes you think we couldn't do login /after/ other
pages? I don't see a real dependency there at all. What am I missing?
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| John Roth 2004-09-28, 4:07 pm |
|
"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:0r-dncFzIvfZOMXcRVn-qA@comcast.com...
>I think this deserves its own thread, so I've
> reposted it out of the 'Estimating' thread with
> additional comments....
As I just posted in answer to one of Ron's questions:
Business value is something that will increase
revenue or reduce costs while still protecting
all stakeholder's interests.
John Roth
>
>
| |
| George 2004-09-28, 4:07 pm |
|
Ilja Preuß wrote:
> Because they discuss what they will do in the morning (Stand Up Meeting),
> all work in the same room and pair program with a different partner every
> few hours?
And in the daily meeting why would i talk about a part
of the story that i haven't got to yet because
i haven't started coding yet? This seems contradictory.
Should i talk about all the other classes i don't
know about yet too?
>
> Because it isn't obvious - you just think it is. Seriously.
I just think you are condescending. Seriously.
>
> And that's exactly why we should defer the effort until we really need it.
You really need it. Every stateful web app needs a bullet proof
login. The issues are wide and deep. If you haven't done it
before you will be very surprised.
> Well, we did exactly that: wrote a web frontend for an
> until-then-swing-application that needed users to login and deferred the
> implementation of the login until ws after the first deployment.
It's a duh you can defer it. The question is with 5 people with
a login in their story would all of them make a seperate stub
or would you converge on a single solution before they checkin?
Robert says you'll make 5 different ones. And that makes sense and
is not necessarily bad. You seem to think it is bad and trying
to make up a scenario where it won't happen.
But some others are saying we'll magically talk about
something we haven't done yet at a meeting or some how during
the day.
| |
| George 2004-09-28, 4:07 pm |
|
John Roth wrote:
> Business value is something that will increase
> revenue or reduce costs while still protecting
> all stakeholder's interests.
Can't it just be something the customer wants?
They don't really need a reason that makes
sense to you.
| |
| Scott Kinney 2004-09-28, 4:07 pm |
|
"George" <somewhere@nowhere.com> wrote in message
news:10lisopmr1rfb52@news.supernews.com...
>
>
> John Roth wrote:
>
> Can't it just be something the customer wants?
> They don't really need a reason that makes
> sense to you.
1. Something that the customer wants; absent
a business driver, is a preference, not a value.
2. If their reason doesn't make sense to you, you
don't understand their needs or business very well.
You should probably ask.
'Value' as John (increased revenue, reduced cost) and I
(increased productivity, which covers a multitude of
conditions) is concrete and measurable.
| |
|
| George wrote:
> John Roth wrote:
>
> Can't it just be something the customer wants?
> They don't really need a reason that makes
> sense to you.
It ain't XP until you release a working version to real users, they use it,
it boosts their productivity, and they give feedback.
Put another way, the best possible feedback for a system is boosts in end
user productivity.
(If your project is online gambling, the best feedback is reductions in user
productivity.)
So, if your onsite customer has indeed set the autopilot for the center of
the Earth, the Customer and Developer Bills of Rights don't let you fix
things, but you can at least detect the poor situation early and often.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
|
| George wrote:
> And in the daily meeting why would i talk about a part
> of the story that i haven't got to yet because
> i haven't started coding yet? This seems contradictory.
> Should i talk about all the other classes i don't
> know about yet too?
Because the standup meeting is about yesterday's successes and today's
concerns.
> You really need it. Every stateful web app needs a bullet proof
> login. The issues are wide and deep. If you haven't done it
> before you will be very surprised.
Pick one:
- security
- internationalization
- concurrency
- data integrity
They are all things we have (generally) bad memories trying to retrofit into
an existing system. Such memories are (generally) untainted by TDD. There is
simply no comparison between hacking complex code and adding features to
simple code.
> It's a duh you can defer it. The question is with 5 people with
> a login in their story would all of them make a seperate stub
> or would you converge on a single solution before they checkin?
>
> Robert says you'll make 5 different ones. And that makes sense and
> is not necessarily bad. You seem to think it is bad and trying
> to make up a scenario where it won't happen.
>
> But some others are saying we'll magically talk about
> something we haven't done yet at a meeting or some how during
> the day.
Uh, I lost track. Why are 5 similar user story cards on the bulletin board?
In general, questions about specific XP practices have answers in other
practices...
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Ilja Preuß 2004-09-28, 4:07 pm |
| George wrote:
> Ilja Preuß wrote:
>
> And in the daily meeting why would i talk about a part
> of the story that i haven't got to yet because
> i haven't started coding yet? This seems contradictory.
> Should i talk about all the other classes i don't
> know about yet too?
Well, if it's really obvious that you need it, you might say something like
"I will work on page Foo today, and I think I will at least need to fake
Login for that."
Then someone might answer "That's great, I will need that, too. Perhaps we
can pair on it? Or we could at least decide on an interface..."
Or, if it doesn't come up in the meeting, somewhere during the day you say
to your partner "Rats, we need to have Login for what we are doing" and
another pair might hear that and suggest "aren't Bertram and Susie needing
that, too? Perhaps you should speak with them." To which Susie answers "We
already have an interface designed - take a look at it. If you agree that
it's meeting your needs, we can commit it to the repository in a minute."
>
> I just think you are condescending. Seriously.
Sorry, didn't mean to sound that way. It's just my experience that there is
always a choice - if I think that something obviously *needs* to done a
certain way, I take that as a sign that I haven't thought enough about the
alternatives.
>
> You really need it. Every stateful web app needs a bullet proof
> login.
I don't by it. And more importantly, I don't buy that you need it now, that
without it you are not able to tackle feature Foo.
> The issues are wide and deep. If you haven't done it
> before you will be very surprised.
If login provides less value to the customer than the feature I am currently
working on, that doesn't sound too intimidating to me...
> It's a duh you can defer it. The question is with 5 people with
> a login in their story would all of them make a seperate stub
> or would you converge on a single solution before they checkin?
That's news to me.
I think it's more likely that they will find out about their matching needs
and find a solution together. There is no guarantee that this will happen,
of course.
> But some others are saying we'll magically talk about
> something we haven't done yet at a meeting or some how during
> the day.
Not magically, but simply because of the fact that in a tightly
collaborating team, you are very aware of what your coworkers are doing.
Cheers, Ilja
| |
| George 2004-09-28, 4:07 pm |
|
Phlip wrote:
> It ain't XP until you release a working version to real users, they use it,
> it boosts their productivity, and they give feedback.
Do you keep a wide variety of industries in mind in your posts?
Getting a SNMP trap when power spikes low is a critical story
but doesn't increase productivity, except in the same way
as anything you want to have happen increases productivity.
Their feedback will be check, it happens.
| |
| George 2004-09-28, 4:07 pm |
|
Phlip wrote:
> Because the standup meeting is about yesterday's successes and today's
> concerns.
Why would i have a concern about something i haven't
started yet? I won't even know i need a login until
i start coding.
> Uh, I lost track. Why are 5 similar user story cards on the bulletin board?
They wouldn't have to be similar to involve the login as a login
involves nearly every story.
> In general, questions about specific XP practices have answers in other
> practices...
Much like religion. Then there's the "it's mystery." Nothing
negative or no downside can ever be allowed.
| |
| George 2004-09-28, 4:07 pm |
|
Ilja Preuß wrote:
> Well, if it's really obvious that you need it, you might say something like
> "I will work on page Foo today, and I think I will at least need to fake
> Login for that."
Why would i say that when i haven't begun coding yet
which is presumably when and where i would say i need
to have a login happen?
| |
| Scott Kinney 2004-09-28, 4:07 pm |
|
"George" <somewhere@nowhere.com> wrote in message
news:10liul8qblv7rd8@news.supernews.com...
>
> Phlip wrote:
it,[color=darkred]
>
> Do you keep a wide variety of industries in mind in your posts?
>
> Getting a SNMP trap when power spikes low is a critical story
> but doesn't increase productivity, except in the same way
> as anything you want to have happen increases productivity.
>
In that case 'boosting productivity' would probably be measured
against the cost, difficulty, limits, timeliness, etc. of how that
function was performed *before* your project was implemented.
| |
| George 2004-09-28, 4:07 pm |
|
Scott Kinney wrote:
> In that case 'boosting productivity' would probably be measured
> against the cost, difficulty, limits, timeliness, etc. of how that
> function was performed *before* your project was implemented.
Why can't something just be a feature because that's what
the customer wants? It all seems somewhat tortured
to bring in a false productivity and feedback. measurement
In this case there was no previous way to do it before
because this is a new product.
If you are making a media center you don't compare MP3
playback with a record player. MP3 playpack is part of the
product definition because that's what the customer wants.
| |
|
| Going forward, please reply to posts' conclusions instead of their premises
and introductions.
George wrote:
> Phlip wrote:
it,[color=darkred]
>
> Do you keep a wide variety of industries in mind in your posts?
I mentioned online gambling.
Your reply is /why/ I mentioned online gambling. Everyone knows not all
features support users working in their sweatshops.
> Much like religion. Then there's the "it's mystery." Nothing
> negative or no downside can ever be allowed.
Well, if it's going to be one of those threads...
....religion requires faith. XP is an example of the scientific process:
http://www.sdtimes.com/opinions/guestview1.htm
That leverages a slightly different aspect of faith.
You asked (I think) how to avoid writing 5 different logins. The answers
are...
- mention what you might do today, during standup.
- pair program with someone who might have written a login
- continuously integrate, and discover someone checked in a login
- work in the same room, and overhear someone working on a login
- write 5 different logins, then delete the 4 least simple ones
Each is a different practice that incidentally covers part of that problem.
Each also has their own downsides, and their own costs and benefits.
Balancing them is engineering.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
|
| George wrote:
> Why can't something just be a feature because that's what
> the customer wants? It all seems somewhat tortured
> to bring in a false productivity and feedback. measurement
The best feedback is gains in user productivity.
If your project is online gambling, you naturally target reductions in user
productivity. All software engineers endeavor to efficiently produce
features that add value. Selling those features is secondary. Demonstrating
the ability to reap the rewards of their value is primary.
"Productivity" is the word for the thing the customer really needs,
regardless of what they say they want. The only way, in engineering, to get
something is to measure it. No software methodology works without feedback
from either field use or a simulation.
Again, all XP practices have side-benefits that help other practices. The
benefit of early boosts in user productivity might - sometimes - be running
a project at a profit instead of on credit.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Scott Kinney 2004-09-28, 4:07 pm |
|
"George" <somewhere@nowhere.com> wrote in message
news:10lj0l59gaf2d78@news.supernews.com...
>
>
> Scott Kinney wrote:
>
> Why can't something just be a feature because that's what
> the customer wants? It all seems somewhat tortured
> to bring in a false productivity and feedback. measurement
>
Of course something can be a feature because that's what the
customer wants. The feature can also be prioritized using some
aesthetic or preference scheme.
At some point, though, someone will want to know if
what was delivered was worth the money spent on it.
> In this case there was no previous way to do it before
> because this is a new product.
>
Then, that's your answer.
| |
| George 2004-09-28, 4:07 pm |
|
Phlip wrote:
> The best feedback is gains in user productivity.
The best feedback is if the customer is happy. You
aren't being extreme enough. Tying success to all
these other measures is over complex and unecessary.
The customer is smart enough to figure out when
they are happy.
| |
| George 2004-09-28, 4:07 pm |
|
Scott Kinney wrote:
> Then, that's your answer.
Which was far different than the original doctrine
based answer.
| |
|
| George wrote:
> Phlip wrote:
>
> The best feedback is if the customer is happy. You
> aren't being extreme enough. Tying success to all
> these other measures is over complex and unecessary.
> The customer is smart enough to figure out when
> they are happy.
Online gambling addicts are happy?
;-)
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Corey Burnett 2004-09-28, 4:07 pm |
| Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<gdlil0tifp0gh1vdl8nsvhm1arkad63qh2@4ax.com>...
> If it's obvious, then certainly it'll be recognized. In this case, as
> I'll mention below, I suspect there's no dependency at all, or not
> much of one.
>
> I don't fear them either, because I've learned there aren't as many as
> I thought.
>
> For example, what makes you think we couldn't do login /after/ other
> pages? I don't see a real dependency there at all. What am I missing?
>
Let's say that there are 4 application stories that involve data
entry, etc. And there is one login story. You are saying that we can
always defer the login story and just implement it later and go ahead
and turn the developers loose on the 4 application stories.
Let's say that in the detailed requirements for the 4 different
application stories we learn that there are 5 different types of
users. And the screens are dynamic in that they will display
different controls and sections depending on what user group you
belong to. And the system will allow you to view all data but only
edit your data. Most likely these requirements would come out in the
detailed requirements for the 4 different application stories.
What a lot of us are used to doing is recognizing that the
implementation of that security model is vital to the application - I
almost think of it as a foundation. And if I was building one of the
4 different application stories it sure would be helpful to have that
foundation working before I started working on my particular module.
It sure would make testing easier if I could go ahead and actually
create the test users in the system and see it all working together.
But what I think you are saying is that the security stuff doesn't
actually need to be implemented. The team simply needs to agree on
what the outcome of a successful login would be. In a web application
the team might decide that when a user successfully logs in that the
system will create a non-persistent cookie on the client machine that
holds the user ID. If all of the developers know that in advance,
then they can go ahead and build story #3 and the actual login screens
and functionality can be developed later.
This is true to an extent. In my above scenario all of the developers
would still probably have to agree on the database schema for holding
all of the user/group/security information so that they would know how
to query it when building their section. Again - the screens for
logging in might not need to be built - but the database or storage
mechanism would need to be agreed on. In practice I think that
agreeing on the database schema is probably more than just a quick 5
minute meeting. I think that is why most of us look at the security
model as a dependency in building this application. If we build all
of that ahead of time then there is no question how the security model
works and all of the developers can use it during their module
development.
I am very curious as to how XP would tackle this. My guess is "do
just enough work". So the developers might meet and flesh out the
database schema for holding all of the security / users / group
information and then leave it at that. They wouldn't implement any of
the login screens.
I can't shake the feeling however that this could be a nightmare. It
would seem to me that you might uncover requirements in the
login/security stories that would affect previously developed modules
and force you to go back and touch every page already developed.
Maybe I don't have a good grasp yet on the concept of loose coupling.
I am getting the feeling that loosely coupled components in an
application make it much easier to build them in any sequence. I
think that more advanced/experienced object oriented developers tend
to just think in a loosely coupled manor where as I probably tend to
think in a more tightly coupled manor.
Sorry for the long post - lots of thoughts swimming through my head.
Corey
| |
| Scott Kinney 2004-09-28, 4:07 pm |
|
"George" <somewhere@nowhere.com> wrote in message
news:10lj444om9en2cf@news.supernews.com...
>
>
> Scott Kinney wrote:
>
> Which was far different than the original doctrine
> based answer.
I don't see how. What makes it different for you?
| |
| John Roth 2004-09-28, 4:07 pm |
|
"George" <somewhere@nowhere.com> wrote in message
news:10liul8qblv7rd8@news.supernews.com...
>
> Phlip wrote:
>
> Do you keep a wide variety of industries in mind in your posts?
>
> Getting a SNMP trap when power spikes low is a critical story
> but doesn't increase productivity, except in the same way
> as anything you want to have happen increases productivity.
This one's simple. It protects a stakeholder's
interests. Protecting stakeholder's interests
is paramount - if you don't your product will
have real problems.
I'm told the US Dept. of Labor defines
productivity as "revenue / # people required to
create that revenue" (note - that's not
"salary required to create that revenue).
It's a measure that's defined externally to
the entire firm.
John Roth
| |
| Ilja Preuß 2004-09-28, 4:07 pm |
| George wrote:
> Ilja Preuß wrote:
>
> Why would i say that when i haven't begun coding yet
> which is presumably when and where i would say i need
> to have a login happen?
Sorry, I think I don't understand that question.
Confused, Ilja
| |
| Ilja Preuß 2004-09-28, 9:27 pm |
| Corey Burnett wrote:
> The team simply needs to agree on
> what the outcome of a successful login would be. In a web application
> the team might decide that when a user successfully logs in that the
> system will create a non-persistent cookie on the client machine that
> holds the user ID.
That's an implementation detail that you can defer, too.
> In my above scenario all of the developers
> would still probably have to agree on the database schema for holding
> all of the user/group/security information so that they would know how
> to query it when building their section.
Uh, no. They shouldn't even need to know that the data is coming from a
database at all. They should only need to know about the interface of
security module; in fact the first implementation could easily work with
hardcoded data.
Cheers, Ilja
| |
| Ilja Preuß 2004-09-28, 9:27 pm |
| George wrote:
> Phlip wrote:
>
> Why would i have a concern about something i haven't
> started yet?
Because you've already talked about it in the iteration planning meeting.
Because you already thought about it.
> I won't even know i need a login until
> i start coding.
Wasn't it you who said that it was obvious you needed a login???
>
> Much like religion. Then there's the "it's mystery." Nothing
> negative or no downside can ever be allowed.
That makes me wonder wether you are really interested in learning more about
XP. Are you?
Cheers, Ilja
| |
| Laurent Bossavit 2004-09-28, 9:27 pm |
| Corey,
> I am getting the feeling that loosely coupled components in an
> application make it much easier to build them in any sequence.
It's one of the (many) meanings of modularity - "modular composability"
to use Bertrand Meyer's terminology from OOSC.
Conversely, building in the "logical" order, i.e. that in which the
functions are used, is said to lead to less than optimal modularity.
Laurent
http://bossavit.com/thoughts/
| |
| George 2004-09-28, 9:27 pm |
|
Ilja Preuß wrote:
> Because you've already talked about it in the iteration planning meeting.
> Because you already thought about it.
Why would i have thought about before i programmed? I
thought i was designing as i was programming, not
before. Do you want to see a class diagram or something?
If not how much of the stuff am i to have thought
about to bring up in the iteration meeting? What
if we all just figure it out as we are implementing
our stories?
> Wasn't it you who said that it was obvious you needed a login???
Yes. But i am not the one saying doing end-to-end stories
even when there's a logical dependency point which could
be done before.
At least robert was honest in what would happen. He didn't try
to say how all these magic channels or meetings would have solve
the obvious result that everyone would create an intermediate
login subsystem.
> That makes me wonder wether you are really interested in learning more about
> XP. Are you?
You make me wonder if you are really interested in anything
other than preaching to the converted. Are you?
| |
| Andrew McDonagh 2004-09-28, 9:27 pm |
| Scott Kinney wrote:
> I think this deserves its own thread, so I've
> reposted it out of the 'Estimating' thread with
> additional comments....
>
Cool, I was unsure whether it warranted it, but going from the reposes
you were right!
snipped.
>
>
> From the customer's point of view, business value is more
> about how completely they can do their work in the new
> application.
I realise my original post might not have been as clear as I hoped.
Business value is not solely addressed by having an installable and
usable product, because my customers tell me it isn't the only value.
Also, as a customer myself (though not in an XP manner), I know getting
the thing I ordered is only part of its value.
I understand Philip et al's reasoning about usable installable software
being the only 'true' business value generator, but my own experience
tells me it isn't.
Lets take the 'building a house' scenario (which is easy for me seeing
as I've just been the customer for buying a new build house).
As a customer, before I received my fully working and installable house
the biggest business values my contractors provided me with were:
1) Being informed of the build progress against schedule
2) Being able to make amendments to features that have only been
partially completed, but aren't usable.
3) eventually knowing when I'm going to get my house finished .
Its a simple example and there's plenty of ways of saying it does/n't
correlate to software. But at the end of the day its an example of how
having software with finished features, involves a journey and keeping
the customer informed and allowing them to make course corrections is
considered by most customers AS important a business value AS the
finished feature.
Its worth noting, that with a lot of XP projects, the customer is a
ProxyCustomer typically an internal Project Manager. They are the
OneCustomerVoice.
To them XP provides business values of not only what is described about,
but also things like being able to see how resources are being used, how
de/increasing those resource might effect the products development etc.
So, the purpose of my original post is to try and highlight that having
finished features as the sole business value generators is too simplest,
however noble.
Andrew
| |
| Andrew McDonagh 2004-09-28, 9:27 pm |
| George wrote:
>
>
> Ilja Preuß wrote:
>
>
>
> Why would i have thought about before i programmed? I
> thought i was designing as i was programming, not
> before. Do you want to see a class diagram or something?
> If not how much of the stuff am i to have thought
> about to bring up in the iteration meeting? What
> if we all just figure it out as we are implementing
> our stories?
Hi George,
From my own experience, this particular example would 'likely' have
been discussed either at the release planning game or the iteration
planning game when the original story was being discussed.
In either of those two games, if the requirements for the login were
discussed, then the customer would have made a decision as to what level
of sophistication they wanted. This would then be fed back into the
plan either by additional tasks for existing story(ies), a simple note
on existing story card9s) say 'login is not required' or even as a
stand-alone story.
Its certainly possible that the requirement was missed from these to
games and only discovered when the original story was being implemented.
In those circumstances, its usual for the developers to talk to the
OnSiteCustomer and say "hay bob we think we'll need some form of ....'
and so starting the conversation and ending with the same results
described above, should that conversation have occurred during the
planning games.
| |
| John Roth 2004-09-28, 9:27 pm |
|
"Andrew McDonagh" <news@andrewcdonagh.f2s.com> wrote in message
news:cjcp8l$6ti$1@news.freedom2surf.net...
> Scott Kinney wrote:
>
> Cool, I was unsure whether it warranted it, but going from the reposes you
> were right!
>
> snipped.
>
>
> I realise my original post might not have been as clear as I hoped.
>
> Business value is not solely addressed by having an installable and usable
> product, because my customers tell me it isn't the only value.
>
> Also, as a customer myself (though not in an XP manner), I know getting
> the thing I ordered is only part of its value.
>
> I understand Philip et al's reasoning about usable installable software
> being the only 'true' business value generator, but my own experience
> tells me it isn't.
>
> Lets take the 'building a house' scenario (which is easy for me seeing as
> I've just been the customer for buying a new build house).
>
> As a customer, before I received my fully working and installable house
> the biggest business values my contractors provided me with were:
> 1) Being informed of the build progress against schedule
> 2) Being able to make amendments to features that have only been partially
> completed, but aren't usable.
> 3) eventually knowing when I'm going to get my house finished .
Does any of this have one thing to do with the assessed valuation
of the house?
No, it doesn't. The only thing that has to do with the assessed
value of the house is the house itself at the time the assessor
comes through.
Now, a failure in project management might well result in a
house with a lower assessed value than projected. However,
that doesn't mean that project management is going to incfrease
the value of the house. It simply means that you've got a
chance to apply damage control early enough to do some
good if the construction process goes out of control.
> Its a simple example and there's plenty of ways of saying it does/n't
> correlate to software. But at the end of the day its an example of how
> having software with finished features, involves a journey and keeping the
> customer informed and allowing them to make course corrections is
> considered by most customers AS important a business value AS the finished
> feature.
Then the customer needs a bit of education, and I mean
that seriously. No amount of project monitoring is ever
going to book revenue or reduce costs. At best it will
allow the customer to see that the project is on track,
and do some damage control early enough to do some
good if it isn't.
Agile processes in general, and XP in particular,
provide substantially better project monitoring,
changability and maintainability than classical
plan driven processes, and they do this without
having to add additional monitoring processses.
>
> Its worth noting, that with a lot of XP projects, the customer is a
> ProxyCustomer typically an internal Project Manager. They are the
> OneCustomerVoice.
Then you could well be headed for trouble. The project
manager is not the customer, and calling him the
customer is simple confusion.
> To them XP provides business values of not only what is described about,
> but also things like being able to see how resources are being used, how
> de/increasing those resource might effect the products development etc.
A proxy customer is not the customer. To be very
blunt about it, I could refer to Abraham Lincoln's
story about the number of legs on a dog. Calling a
dog's tail a leg does not make it one.
> So, the purpose of my original post is to try and highlight that having
> finished features as the sole business value generators is too simplest,
> however noble.
To reiterate, project management does not book revenue
or reduce costs. That doesn't mean that it isn't valuable,
but its value is in a different venue than either additional
revenue or reduced cost.
John Roth
>
> Andrew
| |
| Robert C. Martin 2004-09-29, 10:57 am |
| On 28 Sep 2004 12:09:58 -0700, theburnetts@yahoo.com (Corey Burnett)
wrote:
>What a lot of us are used to doing is recognizing that the
>implementation of that security model is vital to the application - I
>almost think of it as a foundation. And if I was building one of the
>4 different application stories it sure would be helpful to have that
>foundation working before I started working on my particular module.
Why? At most what you need is the interface to the module. You can
stub it out and get your stuff working without the security model
working.
Indeed, it's likely that you wouldn't even need the detailed interface
to the security model. You could probably make a guess at what it was
likely to be. It'd be advisable to go talk to the security guys and
see what they're currently thinking. That would minimize any
retrofitting you'd need to do later.
-----
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-29, 10:57 am |
| On 28 Sep 2004 12:09:58 -0700, theburnetts@yahoo.com (Corey Burnett)
wrote:
>I can't shake the feeling however that this could be a nightmare. It
>would seem to me that you might uncover requirements in the
>login/security stories that would affect previously developed modules
>and force you to go back and touch every page already developed.
You might. And if you worked it all out up front the customer might
change the requirements on you and force the same thing. Or even if
the customer didn't change the requirements on you (ha!) you might
find that one of your design decisions just turned out to be wrong
(ha!) and that you still have to go back and touch every module.
In the end what you need is an easy way to touch every module! Tests
are a *huge* help with 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
| |
| Ilja Preuß 2004-09-29, 10:57 am |
| George wrote:
> Ilja Preuß wrote:
>
> Why would i have thought about before i programmed?
Well, you obviously did, didn't you?
> I
> thought i was designing as i was programming, not
> before.
Then you thought wrongly.
> Do you want to see a class diagram or something?
No. And you obviously didn't need one to see that you might need to stub the
Login.
> If not how much of the stuff am i to have thought
> about to bring up in the iteration meeting? What
> if we all just figure it out as we are implementing
> our stories?
Then you probably couldn't estimate the stories. Therefore you discuss just
enough that you are confident your estimate is accurate enough.
So the discussion could go something like this:
"For Foo, we only have to flubbergist the noodly. We already did something
similar with Boost, so I think it's a 1."
"Uh, but don't we have to do the whole Login for that, too?"
(customer) "Login isn't that important, yet. For the first installation it
would suffice if we only had one default user."
"OK, we can stub the Login. I think that makes it still a 1."
>
> Yes.
So you "knew" that you needed it, without doing an elaborate design or
starting to code, didn't you?
> At least robert was honest in what would happen.
If you think I'm not honest, we should stop the discussion here.
>
> You make me wonder if you are really interested in anything
> other than preaching to the converted. Are you?
I'm not interested in preaching at all. I am here to read about the
experience of others, and to share my experience with those who are
interested. I am here to learn.
Why are you here?
Ilja
| |
| Phlip 2004-09-29, 10:57 am |
| George wrote:
>
> Ilja Preuß wrote:
meeting.[color=darkred]
>
> Why would i have thought about before i programmed? I
> thought i was designing as i was programming, not
> before. Do you want to see a class diagram or something?
> If not how much of the stuff am i to have thought
> about to bring up in the iteration meeting? What
> if we all just figure it out as we are implementing
> our stories?
I want to show up to work drunk, on something (you pick what), without
sleeping last night, and:
==> NOT F*** UP. <==
All the mind games we have been describing are ways to not f*** up. Of
course, in practice, we plan, draw UML diagrams, speculate on future
features, etc. However, those are the optional parts. The parts that prevent
us from f***ing up - pairing, TDD, short iterations - are not optional.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Corey Burnett 2004-09-29, 10:57 am |
| "Ilja Preuß" <it@iljapreuss.de> wrote in message news:<4159c67b$1@news.totallyobjects.com>...
> Corey Burnett wrote:
>
> That's an implementation detail that you can defer, too.
>
>
> Uh, no. They shouldn't even need to know that the data is coming from a
> database at all. They should only need to know about the interface of
> security module; in fact the first implementation could easily work with
> hardcoded data.
>
> Cheers, Ilja
I have to say that I am a bit lost in understanding how XP works from
a very practical perspective. At times it seems like so much "hand
waving" and "magic". Kind of a "trust me, it will all work out" kind
of thing. From the posts I am reading here it seems like a team of
developers never need to agree on anything up front and you can build
an application in any order you want and it will always end up better
than if you had planned it. "Just start coding, Corey and trust me -
it will work. There's no need to try and design a system up front -
it will design itself."
In a weird way it almost seems like evolution vs. creationism. Don't
try and play God and design the world in advance. The world (and your
application) will work itself out the naturally best way - survival of
the fittest.
I think the difficulty for me may be that I don't currently think in
an object-oriented way. I tend to think more procedurely. I don't
always have the ability to view a problem domain and then abstract out
the object model in my head in a very loosely coupled way. I always
see dependencies. Dependencies lead to a greater need for up front
design and planning. Loose coupling leads to greater independence and
less of a need to design and plan up front. So maybe it just comes
down to experience and learning more about how to design my classes so
that they are more independent of other classes and modules.
Corey
| |
| Phlip 2004-09-29, 10:57 am |
| Corey Burnett wrote:
> I have to say that I am a bit lost in understanding how XP works from
> a very practical perspective. At times it seems like so much "hand
> waving" and "magic". Kind of a "trust me, it will all work out" kind
> of thing.
Programming is a creative design process where, traditionally, creativity
carried enormous risks.
Non-creative high-risk situations, like open heart surgery, require exact
recipes, sequences of operations, and contingency plans. And those are
exactly what creative processes don't need, because they add risk too.
Different kinds of risks.
> From the posts I am reading here it seems like a team of
> developers never need to agree on anything up front and you can build
> an application in any order you want and it will always end up better
> than if you had planned it. "Just start coding, Corey and trust me -
> it will work. There's no need to try and design a system up front -
> it will design itself."
Unfortunately yes. Here's why:
- the contingency plan is test test test test test test
- if you have checks and balances, such as tests, then
using code to s a design is lower risk than
planning a design. The risk is over-design and
excess cruft that's hard to remove
- projects scale only as long as their cruft is controlled
If we all had brains the size of a planet, we could write and then read
entire requirements documents, and type entire programs from top to bottom.
We can't, and pretending we can adds risks.
> In a weird way it almost seems like evolution vs. creationism. Don't
> try and play God and design the world in advance. The world (and your
> application) will work itself out the naturally best way - survival of
> the fittest.
Well, artificial selection has given us big juicy apples instead of little
hard sour ones.
> I think the difficulty for me may be that I don't currently think in
> an object-oriented way. I tend to think more procedurely. I don't
> always have the ability to view a problem domain and then abstract out
> the object model in my head in a very loosely coupled way. I always
> see dependencies. Dependencies lead to a greater need for up front
> design and planning. Loose coupling leads to greater independence and
> less of a need to design and plan up front. So maybe it just comes
> down to experience and learning more about how to design my classes so
> that they are more independent of other classes and modules.
Test, code, refactor, and pair. When you discover coupling, decouple it.
Under continous review, such issues get fixed very early, before they grow
to become problems.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Ilja Preuß 2004-09-29, 8:04 pm |
| Corey Burnett wrote:
>
> I have to say that I am a bit lost in understanding how XP works from
> a very practical perspective. At times it seems like so much "hand
> waving" and "magic".
What do you feel is magic about deciding on an interface way before deciding
on how to implement it? Serious question.
> Kind of a "trust me, it will all work out" kind
> of thing.
Well, to some amount, it is. To do the above, you need to be confident that
you can implement the "real thing" way later. If you don't trust yourself to
be able to do that, it certainly looks like a lot of risk.
> From the posts I am reading here it seems like a team of
> developers never need to agree on anything up front and you can build
> an application in any order you want and it will always end up better
> than if you had planned it.
Well, only if you know how to do it, I'd suppose.
> "Just start coding,
Well, not exactly...
> Corey and trust me -
> it will work. There's no need to try and design a system up front -
Correct.
> it will design itself."
Certainly not! We will design it while we implement it, not upfront.
> In a weird way it almost seems like evolution vs. creationism. Don't
> try and play God and design the world in advance. The world (and your
> application) will work itself out the naturally best way - survival of
> the fittest.
No. And if I remember correctly, God didn't plan the whole 6 days in
advance...
> I think the difficulty for me may be that I don't currently think in
> an object-oriented way. I tend to think more procedurely. I don't
> always have the ability to view a problem domain and then abstract out
> the object model in my head in a very loosely coupled way.
I can't do that, either.
> I always
> see dependencies. Dependencies lead to a greater need for up front
> design and planning.
I think it's the other way around: because I can't abstract out the object
model in my head, I need early feedback from the code.
> So maybe it just comes
> down to experience and learning more about how to design my classes so
> that they are more independent of other classes and modules.
That certainly is an important skill - wether you are doing upfront or
ongoing design.
Evolutionary design has nothing to do with magic - it needs skill and
experience, as does upfront design. In my experience the skills necessary
for evolutionary design are easier to learn and lead to more effective
designs, though.
Cheers, Ilja
| |
| John Roth 2004-09-29, 8:04 pm |
|
"Corey Burnett" <theburnetts@yahoo.com> wrote in message
news:73447641.0409290459.360f5a20@posting.google.com...
> "Ilja Preuß" <it@iljapreuss.de> wrote in message
> news:<4159c67b$1@news.totallyobjects.com>...
>
> I have to say that I am a bit lost in understanding how XP works from
> a very practical perspective. At times it seems like so much "hand
> waving" and "magic". Kind of a "trust me, it will all work out" kind
> of thing. From the posts I am reading here it seems like a team of
> developers never need to agree on anything up front and you can build
> an application in any order you want and it will always end up better
> than if you had planned it. "Just start coding, Corey and trust me -
> it will work. There's no need to try and design a system up front -
> it will design itself."
The core concept that makes it all work for me is something that
a lot of people miss, mostly because it goes against a lot of very
painfully acquired experiance.
XP's software development process has one overall goal:
maintaining the code base in a form where any given change
costs about the same regardless of when in the project the
need is discovered or it's
installed. In other words, it flattens the cost of change curve
for new (and changed) functionality. (That is not the same
as the cost of change curve for defects - that's a completely
different issue that is unfortunately  with the functionality
issue.)
When you can do that, you realize that you don't need detailed
requirements or design up front. They simply get in the way.
What you do need up front is a "big picture" idea of what the
project is all about. The details can wait until they're actually
needed.
That big picture is vital, but it's something that needs to be
supplied by the project sponsor. That's part of business strategy
planning, not software development.
> In a weird way it almost seems like evolution vs. creationism. Don't
> try and play God and design the world in advance. The world (and your
> application) will work itself out the naturally best way - survival of
> the fittest.
> I think the difficulty for me may be that I don't currently think in
> an object-oriented way. I tend to think more procedurely. I don't
> always have the ability to view a problem domain and then abstract out
> the object model in my head in a very loosely coupled way. I always
> see dependencies. Dependencies lead to a greater need for up front
> design and planning. Loose coupling leads to greater independence and
> less of a need to design and plan up front. So maybe it just comes
> down to experience and learning more about how to design my classes so
> that they are more independent of other classes and modules.
Well, OO is a tool. I first learned about coupling and cohesion
in a procedural setting; there's nothing magic about OO that
automatically gives you less coupling.
Dependencies don't suddentlydisappear if you use the
magic design technique. They have to be identified,
whacked over the head and eliminated, one by one.
The whole thing about dependencies is that if you build the
software tiny step by tiny step, you have the opportunity to
see the dependencies early, before the cute little lizards turn
into fire breathing dragons.
John Roth
>
> Corey
| |
| Robert C. Martin 2004-09-29, 8:04 pm |
| On 29 Sep 2004 05:59:47 -0700, theburnetts@yahoo.com (Corey Burnett)
wrote:
>I have to say that I am a bit lost in understanding how XP works from
>a very practical perspective. At times it seems like so much "hand
>waving" and "magic". Kind of a "trust me, it will all work out" kind
>of thing. From the posts I am reading here it seems like a team of
>developers never need to agree on anything up front and you can build
>an application in any order you want and it will always end up better
>than if you had planned it.
Another way to look at it is: Agree up front on what you will do for
the next w. Allow that w to influence your agreements for the
following w. Plan for the next w, and allow the results of that
plan to influence the plan for the following w.
You don't have to trust me for more than a w. After that you are
trusting your own observations about what happened the previous w.
>"Just start coding, Corey and trust me -
>it will work. There's no need to try and design a system up front -
>it will design itself."
Another way to look at this is: Continuously design the system.
Design this w's part of the system now, and use the outcome to
influence next w's design. Continuously migrate the design of the
*whole* system each w, keeping that design as flexible and
appropriate as possible.
The only real difference between this kind of design, and up=front
design is that we use code as one of the design tools. We get
feedback from actually building the real system to help us with the
design.
>So maybe it just comes
>down to experience and learning more about how to design my classes so
>that they are more independent of other classes and modules.
Very likely. Experience is the best teacher. The quicker you start
doing it the faster you'll come up to speed.
-----
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
| |
| Ilja Preuß 2004-09-29, 8:04 pm |
| Robert C. Martin wrote:
> On 29 Sep 2004 05:59:47 -0700, theburnetts@yahoo.com (Corey Burnett)
> wrote:
>
> Very likely. Experience is the best teacher. The quicker you start
> doing it the faster you'll come up to speed.
I'd rather say: The earlier you get as definitive feedback as possible, and
the earlier you are able to incorporate your current learning into the
system, the faster you'll come uo to speed.
That's the problem I personally had with bigger upfront design: No matter
how hard I tried to get the upfront design right, the really hard problems I
only found during implementation. And then I only had two options: live with
an inadequate design, or start over...
Cheers, Ilja
|
|
|
|
|