Michael G Schwern writes:
> That sounds bad. I've heard about this style. Code now, refactor
> later. Its supposed to avoid the need for sweeping architectural
> decisions early in the project, allow you to recover from bad design
> decisions and return flexibilty to old code.
Well, yes, but also designed for the situation where you're trying to
hit a moving target (customer keeps changing requirements). Because
we're essentially the customers for this project, I think we're in
a good position to be able to follow the specifications->design->code.
The thought that we may be the only people in a position to do that
scares me. That sounds too good to be true. It doesn't scare me
as much as the prospect of starting coding without designing. The
perl6-* experience has shown that it'll never end if we don't cut
off features at some point.
The hard part is probably going to be resisting the urge to add
features just because they're possible: once we come up with a design,
we must code the design, and leave new features for later 6.x
releases. Feature creep control, in other words.
This all adds up to not following the continuous refactoring approach
to design. In short, I agree :-)
Nat
