Re: Rework [Was: Static vs. Dynamic typing...]

From: Phlip (phlip_cpp_at_yahoo.com)
Date: 07/15/04 

Date: Thu, 15 Jul 2004 21:38:53 GMT

Alan Balmer wrote:

> Phlip wrote:
>
> >Alan Balmer wrote:
> >
> >> Personally, I can fit more than ten minutes in my mind. Teamwork does
> >> not have to be accomplished on a continuous basis. It's perfectly OK
> >> for a member of a team to work all by himself for a few hours, or a
> >> few days, since he and the rest of the team know where he's going.
> >
> >A low truck number is not okay, for reasons unrelated to the actual
truck.
> >I'm not saying you had one...
>
> I have no idea what that means, but it sounds like you are insulting
> me, then claiming you didn't.

No prob.

If I make a huge change, don't tell anyone about it, check-in, leave the
codebase so nothing compiles much less tests, and clock out for the day, I
just put the project at risk, because nobody can support my efforts.

I'm not saying you did that. But...

Any deviation from teamwork and relentless positive testing requires extra
efforts to isolate the temporary bad effects of big changes.

If I make a huge change, leave it in a sand-box on my desk, tell everyone
not to touch modules V, W, X, Y and Z, and leave for the day, I just slowed
everyone else down.

There's just no way to isolate changes without risking Integration Heck when
the time comes to un-isolate them. Forking a codebase is bad.

Relentless testing permits incremental changes that reinforce aspects of the
project that are not undergoing those changes.

> >> I have certainly made sweeping changes taking more than a few days and
> >> had a zero bug count at the end, where it matters. And I'm just as
> >> sure of my "zero bug count" as you are of yours ;-)
> >
> >Halfway thru, if you were certain the bug count is zero, and if all the
> >features still work, and if you could have integrated, released, and
> >deployed, then you were agile.
>
> Why would I want to do that? I can assure you that our customer do not
> want me to do that. "Stand by for your hourly update - we'll have you
> back running in a jiffy."

Agile projects "release" every week, meaning they produce something that
_could_ go all the way to a user. Each release must demonstrate a potential
productivity boost.

The ability to do this is much much more important than actually releasing
to users. But Web sites like Google probably quietly release something very
frequently, because their channel is so short.

> Are you saying that "agile" people are likely not to finish what they
> start?

Agile projects have an extraordinarily low chance of a big change.
Implementing features in order of business value flattens the odds that any
feature deploys and then gets reworked.

However, Agile projects delay expensive decisions until the last cheap
responsible moment. Suppose you start with XML files, and by Iteration 6 the
OnsiteCustomer request features that require concurrent transactions.
Switching to a database is now cheaper than morphing XML files into a
database. And you have 5 iterations of experience, invested in tests,
showing exactly what schema that database will hold. The cost of change is
lowest if it's delayed until proof arrives that you need it.

But suppose the cost of installing that database on your site is very high.
Then you might have only enough time, during iteration 6, to convert some of
your tables from XML to the database. You convert the ones that now need
concurrency, and leave the others in XML.

You can release Iteration 6's version (whether or not the release deploys to
users) even if half your tables use XML and the other half use the database.
Then by iteration 7 you finish the other tables, and retire your XML
modules.

End-users, if any, will not care that Iteration 6's design had room for
improvement. No project should duplicate its persistence layer between two
completely different kinds of databases. The tests don't care either. They
test features and behaviors, not designs, so they still pass.

Each time you predict a successful test run, every few minutes, on each of
>6 workstations, for the same codebase, during all those two weeks, you get
a green bar.

This procedure also has overwhelming benefits to all the parts of the
process that are not undergoing a major change.

> >> 1. You don't break the system.
> >> 2. You get data on your new approach before you are done with it.
> >> 3. The process can be interrupted and later resumed.
> >> 4. You can change course mid stream.
> >> 5. You *always* know the current state of the system.
> >> 6. Everybody else *always* knows the state of the system.
> >> 7. You are never on the critical path.

> This list sort of puzzles me, too. When we make changes to a system,
> we don't shut down the current version while making the new one. We
> certainly don't deliver partially modified versions of the system,
> whether they compile and execute or not.

The /ability/ deploy /any/ integration, every few minutes, no matter how
mutilated the design, is absolutely priceless. To achieve that ability
requires channeling a very high volume of feedback from a project's current
status. That feedback provides the ability to reliably predict the cost of
each change request, no matter how small or big. 

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

Relevant Pages