Alex Thurgood wrote:
Ulf Wendel a écrit :
Yes, absolutely. We don't compromise on that. When we were monosite,
it was not a problem, but now we have multiple sites across multiple
networks, which essentially means duplicating the database (and server
configs) across sites. We're looking at synchronisation/replication as
possible solutions, but that's more overhead.
To me it sounds a bit like a goodie. The initial focus should be on
getting out a working driver out at all. Basic query and connect
should work flawless. Once we have achieved that we can have a look
at SSL.
I would tend to agree. Better to have a (nearly) flawless driver than
one with those extra bells and whistles that are only required by a
few people. However, I don't know how corresponding solutions fare,
for example, does the current native postgres-sdbc driver allow this
kind of thing ? I must admit to not having looked into that aspect yet
(the fact that the postgres driver doesn't run on Mac is a problem for
me there).
Yes working code is better then non-working code. Not recognizing
requirements for a segment of your intended user base is just as much a
bug as a coding mistake however, probably a more serious one and almost
always much more costly to correct in terms of development resources.
Which does not mean that all features for all requirements or use case
scenarios must be activated in the initial release of a piece of
software - it does mean that the overall project plan should account for
them, so that design and implementation decisions can take them into
consideration.
There is a lot of talk of the "Agile" approach to developing software.
One of the tenants of which is - build nothing beyond what you
absolutely must, add nothing that has not been explicitly asked for by
the 'customer'. I agree with that approach particularly in the case of
contract development both in commercial job shops and internal IT
departments. It gets a bit more problematic, it seems to me, for the
general use or 'shrink wrap' markets and to some extent vertical market
vendors ( although they by definition almost should have less of problem
with requirements ). I used the term 'cost of entry' the other day
meaning that if you are waiting to get feedback from a user base as to
what features need to be added to a package you still must start with
some minimal set of requirements sufficient to gain entry into that
market in order to get that user base that can then give you feedback.
i.e. Cost of Entry.
Report Builder may be a pretty good example - The development
organization or organizations decided in advance what those requirements
where and a roadmap was put up very early on for all to see. The actual
code has been releasing along the path put forth in that road map. I
suppose though one could also say that the Report Builder 'project plan'
came out of the feedback from the user base regarding the initial
release of Base and the report wizard.
Thanks
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
