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*.
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 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.
"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.
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.
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.
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.
And now you admit:
"I do not know yet where this corruption occurs. DB Server, Drivers,
In Memory, Saving of the file, Server DB."
"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.
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!
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 ?
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.
I could just give you what you want, but that may not be what you need.
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.
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
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
