Well put ;-)
Alister Christie
Computers for People
Ph: 04 471 1849 Fax: 04 471 1266
http://www.salespartner.co.nz
PO Box 13085
Johnsonville
Wellington
On 18/01/2011 1:40 p.m., Kyley Harris wrote:
I'm wondering if you analyzed your need for popcorn carefullly. You
asked for popcorn.. you got your popcorn. but perhaps you've been
taken for a ride. If we analyze your need carefully for an hour, what
we could have determined is that you truley wanted a 30 minute comedy
show, and some salt - and -vinegar chips to go with it. Not popcorn at
all. Perhaps the desire for popcorn stemmed from your not correctly
seeing your needs in the first place. I feel its my duty to help you
access the situtation so that you get what you need and not what you want.
We could discuss this further privately, and I'm sure with all my
experience in these situations that a 3 hour lunch break daily, with
said included comedies and chips will satisfy your needs more
appropriately.. The Popcorn is just a bandaid.
On Tue, Jan 18, 2011 at 12:44 PM, David Brennan
<dugda...@dbsolutions.co.nz <mailto:dugda...@dbsolutions.co.nz>> wrote:
Mmmm, I'm enjoying my popcorn as I watch...
-----Original Message-----
From: delphi-boun...@delphi.org.nz
<mailto:delphi-boun...@delphi.org.nz>
[mailto:delphi-boun...@delphi.org.nz
<mailto:delphi-boun...@delphi.org.nz>] On
Behalf Of Matthew Comb
Sent: Tuesday, 18 January 2011 11:12 a.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Validating CDS files
> Those developers that came back with "TO DO" lists were perhaps
themselves
> not taking the time to understand the customers problems. The
customer
> told
> them "those 10,000 features are great, but we'd really like X, Y
and Z",
> so
> the developers simply came back to you with that list of "X, Y
and Z".
>
> Far from analysing too much, they were most likely not analysing
*enough*.
What your argument does not take into account yet again (which was my
point that was missed), is the time and money factor. If you have
a 1 day
or 2 day install, you do not have time to spend all 2 days taking on
customer requests when the customer is not yet up to speed with the
capabilities of the system. A customer often doesn't know what
they need
until they get to use the system, then their requirements frequently
change. If you have unlimited time and money then by all means, spend
every waking moment analysing each and every item raised, Cameron
would
probably tear his hair out.
>
>
> That specialist you hired is most likely looking at the X, Y and
Z and
> then
> asking the customer... "But what do you need X, Y and Z for?"
then showing
> them that they already HAVE X, Y and Z among the 10,000 other
features.
>
>
> That quite neatly demonstrates my point I think. Understand the
> problem...
> not only might the solution you are asking for not be ideal, but
you might
> already be in possession of the solution !!!
>
I don't think it does at all.
>
>
> "I have a legacy piece of software which very very rarely
corrupts a
> local data file - fact"
>
> The real problem to be solved is how/why the corruption occurs...
> everything
> else is just sticking plaster, not a solution, and even the sticking
> plaster
> can only help if you apply the right sort of dressing correctly.
Thats right, that is the root problem, but as this piece of
software has
been in the field for 8 years, and is being decommissioned, there
isn't a
lot of point in that is there. So a bandaid is more than adequate.
>
>
> "Regardless of the better long term solutions, we will take
> a defensive programming measure to protect against the loading
> of corrupt files."
>
> And my point in this area was that unless you understand
how/where the
> corruption is occurring, the defensive measures you might take
may very
> well
> end up not being defensive at all.
If you validate a CDS file, and don't load it if it is corrupt.
That is a
defensive measure.
>
> e.g. the idea of checksuming the output from the server... if
the data
> coming from the server is corrupt from the get-go, then
check-summing
> helps
> you not one little bit.
>
Agreed which is why I didn't ask about it.
>
>
> You initially blamed the corruption on a flaky wifi connection -
highly
> unlikely for the reasons that I and others have explained. You then
> explained that you were streaming the data, so the corruption
might occur
> in
> sporadic bytes in the stream.
I do not believe I did suggest the contents of the stream would be
changed. What I said was that a TCP steam can be disconnected.
this was
yet another wild assumption on your part. If you send a 1GB file
through a
stream, it is NOT as Kyley suggested an All or Nothing approach.
You are
taking bytes into a stream. It is up to you whether or not you
discard the
stream based on a disconnection or not. That decision point is out
of my
control as it is Midas + DBX4MySQL which manages this.
>
> But then you seemed attracted to the idea of using XML as a
potential way
> forward, which would seem to contradict the streaming nature of
the data
> transmission.
The incorrect assumption you made at the beginnning was that the
CDS file
was coming from the server as a file payload. Its not. The client is
connecting to MySQL DB server directly. All suggestions and
misunderstandings about hashing, file downloads, etc were based on
that
incorrect assumption.
>
> And now you admit:
>
> "I do not know yet where this corruption occurs. DB Server,
Drivers,
> In Memory, Saving of the file, Server DB."
I don't, and it doesn't matter. Why ? Because at a rate of 1/10000
it is a
manageable issue, and with the software being decommissioned it is
good
business sense to investigate the server mechanics. its better to
bandaid
and move on.
>
>
>
>
>
> "Its not true to take the standpoint that if someone asks for the
> solution
> then they should be able to provide it e.g If I ask for Word
2010
> should
> I be capable of sitting down and writing the application suite?"
>
> I didn't say that they *should* be able to provide it in the
sense that
> you
> took it to mean - I said as to draw attention to the inherent
> contradiction.
> The only way you can confidently ask for a solution in the form of a
> solution specification, without explaining the problem, is if
you fully
> understand the problem and *could* provide the solution
yourself. In
> which
> case, you would never have needed to ask someone else to provide the
> solution for you.
Thats just rubbish.
>
> In other words, when someone asks for a solution, rather than
stating a
> problem, the likelihood is that they are asking for the wrong
solution
> from
> the very start!
Statistically probably correct more often than not, but still an
arrogant
assumption that the person is clueless / uninformed of possible
solutions.
Its also arrogant to assume you know everything abou the
motivation and
drivers as to why the person asked the question in the first place.
For example in this case, the fact that the software is being
decommissioned and the fact that its rarity does not make a server
solution fiscally viable.
>
>
> Your "Word 2010" example this is a quite different sort of
request from
> what
> we are actually discussing (it's not a "technical solution" just a
> shopping
> list), never-the-less even this inappropriate parallel can be
used to
> illustrate the same point:
>
>
> If you ask for Word 2010, should I just sell it to you simply
because you
> can't write it yourself ?
That logic much like the rest of your logic is flawed. I did not
say that
you should sell it to me because I could not program it. You
should sell
it to me because I asked to buy it.
I am asking to buy it, because I don't want to program it.
>
> Or should I first ask what you need it for.... ?
>
> If you tell me you want it for doing bulk emails, and you heard
that Word
> 2010 has some neat mail-merging capabilities, then I am pretty
confident
> that I can sell you a better solution for your needs than just
handing
> over
> a copy of Word 2010.
Again you are incorrectly assuming that the person asking the
question is
a retard.
>
> I could just give you what you want, but that may not be what
you need.
>
Its not your decision to make.
>
> Incidentally, nobody "gave me" a blog. I created my blog in
order to
> share
> my skills and experience and - if my stats are to be believed -
many, many
> people appreciate it.
Actually I've found your blog to be very good and useful. I feel
that if
you reigned in the arrogance a tad, you might get places faster.
> I gain some sense of satisfaction from the fact that people
(well, *some*
> people at least) seem to appreciate my effort, but it certainly
doesn't
> "go
> to my head".
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi@delphi.org.nz <mailto:delphi@delphi.org.nz>
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-requ...@delphi.org.nz
<mailto:delphi-requ...@delphi.org.nz> with Subject:
> unsubscribe
>
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz <mailto:delphi@delphi.org.nz>
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz
<mailto:delphi-requ...@delphi.org.nz> with Subject:
unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz <mailto:delphi@delphi.org.nz>
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz
<mailto:delphi-requ...@delphi.org.nz> with Subject: unsubscribe
--
Kyley Harris
Harris Software
+64-21-671-821
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
