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
>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
>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
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.
Fairly Senior Software Type
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]