[Squeakfoundation]re: TrueType font support and 3.6

[Marcus Denker]

On Sat, Jun 21, 2003 at 06:04:03PM +0200, Daniel Vainsencher wrote:
> Hi Andreas - 
> 
> I'm confused too. Let's try to isolate the problem.
> 
> Claim I - We have a piece of code that's candidate for inclusion. We all
> agree it has flaws as detected by even cursory inspections. 
> 
> Claim II - I percieve as a very obvious, general rule that at every
> stage of mixing code in with more of the real world, the price of fixing
> errors goes up, because problems are easier to solve in isolation.
> Therefore, make it work, make it right, then deploy wider.
> 

Problem is: Claim II is wrong. And obvioulsy so: Adding a big
changeset to Squeak takes a long time: It needs to be reviewed,
and discussed (image or package?). Most of the time those things
are pretty complicated, just because they tuch a lot of stuff 
where not many reviewsers are real experts. So adding big things
takes time.

On the other hand: small, isolated refactorings, that fix a little
thingy at one place can be harvested *very* fast: lots of people
can review a simple refactoring (e.g. removing a direct reference
to a class) without understanding the whole thing that was once that
big changeset. 

Another thing: Adding even not-perfectly working stuff can be good, because
it gets tested by lots of people, and most squeakers who
follow the update stream actively fix bugs they encounter. They
do this for the stuff in the update stream, not for those big changesets
that are in the review process.

So my claim (which is not new btw, it's the basis of the whole "Agile
Development" Hype) is that it's less expensive to fix things later
than most people would intuitivly guess.

  Marcus

-- 
Marcus Denker marcus at ira.uka.de  -- Squeak! http://squeak.de