Re: Migrating a system incrementally. Was: Re: Static vs. Dynamic typing (big advantage or not)
From: Phlip (phlip_cpp_at_yahoo.com)
Date: 07/16/04
- Next message: Dmitry A. Kazakov: "Re: TDD [Was: Static vs. Dynamic typing (big advantage or not)]"
- Previous message: Dmitry A. Kazakov: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management"
- In reply to: Chris Uppal: "Re: Migrating a system incrementally. Was: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP"
- Next in thread: Ilja Preuß: "Re: Migrating a system incrementally. Was: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 16 Jul 2004 14:45:23 GMT
Chris Uppal wrote:
> > > 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.
> > If so then
> > (3), (4), (5), and (6) are all moot.
> It seems to me that (5) and (6) are of little value if the current "state
of
> the system" is "its a mess".
Is the structure or the behavior a mess?
A program's design is the relationships between its structures in memory and
their behavior in time.
During a big incremental change, the structures can mutate, and the
definitions of behavior can duplicate, and if the output behavior remains
exactly the same, then the run-time behavior is not a mess.
> As for (3) and (4), if /I/ were wanting to make extensive changes to a
system
> (whether incrementally or not), I would /far/ prefer to start from a
position
> where the system made sense. In the case described, I don't see how the
> developers deal with the mess unless they have some sort of roadmap of
what
> changes are to be made, and why they are made in that order. This mental
map
> sounds about the same as the one I have in my head if I do a sweeping
change of
> some sort, and would be just as vulnerable to interruptions and changes of
> direction.
To perform a Deprecation Refactor, locate the code to be retired, and write
a comment on it "// this is under deprecation don't use it - see module X".
That's a speed bump. It does not increase risk or bug rates; it just slows
velocity. (Putting all the engineers in one programming pit also helps.)
When tests infect your system, it's a small bump
Tests written while the system is a mess remain perfectly valid as it gets
better.
During a sweeping 2 week change, 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.
> Ilja Preuß wrote:
>
> > If you start improving the current code incrementally, your customer
will
> > get immediate ROI. If you start from scratch, your new system needs to
do
> > at least what the old system is doing to get ROI, which might actually
> > take a while.
> >
> > Does that compute?
>
> Not really. For incremental change /in general/ yes I agree, but we are
> talking about the specific case where sweeping changes (however made) are
> required in order to achieve some benefit. In such case the customer
won't see
> any ROI until the change is complete, however it's made. In such cases I
can
> even imagine the customer refusing to accept incremental changes that
introduce
> extra risk (albeit, with good tests, rather low extra risk) but have zero
> benefit. "Why are you shipping me this ?" I can imagine them asking.
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. They all support the general
ROI, which is always incrementally improving.
-- Phlip http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
- Next message: Dmitry A. Kazakov: "Re: TDD [Was: Static vs. Dynamic typing (big advantage or not)]"
- Previous message: Dmitry A. Kazakov: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management"
- In reply to: Chris Uppal: "Re: Migrating a system incrementally. Was: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP"
- Next in thread: Ilja Preuß: "Re: Migrating a system incrementally. Was: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
