At 12:47 PM 6/8/01 +0100, Alex McLintock wrote:
>I'm not going to argue whether or not a rewrite is a good idea but it is 
>pointless to expect business to pay for the rewrite. Business is all about
>immediate results and immediate profit. Just about every client I've
>ever had says something like "Never mind the quality, just deliver it ASAP."

I don't doubt that clients use those exact words, but when they say 
"quality" what they really mean is "cut down on the testing and the design - 
just code and code fast."

If they knew what we actually mean by software quality, I doubt that they 
would dismiss it. I'll borrow a useful definition from Roger Pressman: 
"conformance to explicitly stated functional and performance requirements, 
explicitly documented development standards, and implicit characteristics 
that are expected of all professionally developed software". Pressman goes 
on to say that "lack of conformance to requirements => lack of quality", 
which is of course absolutely true.

Clients actually expect the above for all other products, and it's only 
ignorance about software development that leads them to assume that software 
is somehow different from cars or houses or cameras when it comes to quality 
as defined above.
>Open Source projects succeed by lots of hands doing many small changes. A
>is best done by one person or small team working dedicated on the project.

I agree, basically.

>If we have to wait three months (say) for the next major release then FOP
will die.
>Unless FOP can be developed in an evolutionary way, rather than a
>way it will fail. 

Well, we will have a reasonably important release within a week. The release 
schedule after that will be driven by what we decide about issues you 
mention below.

>What you are calling for is support (financial/technical/time) so that people
>can build the basis of FOP V2.00
>I'd like to see Fop 0.19 CVS still developed whilst that is going on. I think
>you were saying that it is  difficult to fund this work whilst a redesign is 
>going on. Hmmm. Maybe. Maybe not. I'd say that bug fixing was easier to 
>get paid for than a re-write.

I think this is a pretty good model. It takes a lot of pressure away from 
those of us who want to concentrate on re-architecting and redesign leading 
to a "FOP 2" if we know that immediate work is being done on FOP 0.x, 
leading to a FOP 1.0 beta within 3 months, say, and a FOP 1.0 GA within 6 
months. With this timeline we could shoot for a FOP 2 in early 2002, knowing 
that a decent production-ready FOP 1.0 has been out for at least a few 
months prior.

This timeline for FOP 1.0 is ambitious, _unless_ we get FT or PT-FT 
developers working on the project. My off-the-cuff estimate is that knocking 
FOP 0.x into decent near-production-ready reasonably-well-tested shape would 
require at least 3 person-months of effort, and very possibly closer to 
twice that. I don't think I'm being conservative, either. :-)

Absolutely, we are talking about a few dedicated bodies. Which means 
time==financial resources. It sounds like a number of companies are doing 
this already, which is great. I hope that the balance of this code gets 
folded back into CVS - it will help all concerned.

Arved Sandstrom

Fairly Senior Software Type
e-plicity (
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to