Re: FileReader / BufferedReader Help


"DJ" <ddjames@xxxxxxxxxxxxxxx> wrote in message
news:46bbc096$0$30644$4c368faf@xxxxxxxxxxxxxxxxx
Hi Rhino. Thanks for your suggestions.

"rhino" <No.offline.contact.please@xxxxxxxxxxxxx> wrote in message
news:f9fls0$pmd$1@xxxxxxxxxxxxxxxxxx

I've only just skimmed this thread but the first thought that came to my
mind still seems relevant: why are you "reinventing the wheel"?

I think every improvement comes with a cost of a little reinventing.

There are lots of file-compare utilities out there already, many of which
are free.

<snip>

You may want to consider cost and licencing issues, as well as the format
of the difference report.

Yes, many are apparently free, until you consider use in a corporate,
for-profit enterprsie. Quick; call in the legal department and get a
contract negotiated (not). Then consider the costs to send the app through
a corporate approval process, perform compatibility testing to ensure
there's no impact to existing corporate standard apps, packaging for
distribution, training of support personnel, ad nauseam. Free might be
great for smaller shops but I don't have that luxury.

Writing your own compare utility also has costs associated with it. Or at
least it would in a medium to large shop. Having worked in that environment
as a developer, I was frankly appalled by the bureaucracy in some cases. I
still remember my last week at one job. In that entire week, I spent a grand
total of one hour making a small change - I added a single row to a table in
a COBOL program - and then spent the rest of the week on bureaucracy like
Promotion to Production forms, updating run books, counting productivity
units (it took several hours and the labour of two people to decide
officially that adding a row to a table didn't add a lot to the productivity
of the enterprise), and so on and so forth.

Now, in a small shop, you might avoid much of that. On the other hand, the
bigger shops have evolved those practices because they have proven necessary
in some way. In some cases, it's political: they create numbers that show
the department is doing something. But in many cases, it is to ensure that
everything that goes into production is thoroughly tested to ensure that it
won't break on live data. If you don't take similar steps, you could VERY
easily find yourself in the position of having a production program that
doesn't work correctly and gives you bad results that cost your company
serious dollars.

In any case, I doubt that the average large company actually gets the legal
department involved or draws up contracts just to purchase a file compare
utility. And you are going to have to train people how to use your file
compare utility regardless of whether you write your own or buy one.

This seems likely to be a better use of your time, especially if you are
not a developer.

Perhaps, but I think of it as expanding my horizons and becoming a little
more self-sufficient. I had a few false starts, went down a couple dead
ends, but I wound up with a nice little app that performs the way I need
it to (thanks in part to those in this group). I've learned a lot along
the way and the next time I need a new tool for my Swiss Army knife it
might not be as painful (unless it has to be multi-threaded). I'm not a
developer by trade, but I didn't say that I didn't develop, ;)

Don't get me wrong, I'm not trying to discourage you from developing code! I
love coding and I may be one of the worst offenders when it comes to
building something from scratch that could easily be obtained "off the
shelf". And I would never want to deter anyone from the joy of creating
things that a developer gets (or at least that _I_ get from developing). I'm
just trying to offer the same sort of options that were suggested to me in
past encounters with management.


--
Rhino


.

Relevant Pages

  • Re: VS.NET is too EXPENSIVE. Developers switching rapidly from it.
    ... >> going to switch to Linux because, quite frankly, VS.NET costs way too ... >> much in light of the huge competition from Linux. ... > cost of developer tools is too high then you may want to consider doing ... It is not just the developer tools. ...
    (microsoft.public.vsnet.general)
  • Re: VS.NET is too EXPENSIVE. Developers switching rapidly from it.
    ... >> going to switch to Linux because, quite frankly, VS.NET costs way too ... >> much in light of the huge competition from Linux. ... > cost of developer tools is too high then you may want to consider doing ... It is not just the developer tools. ...
    (comp.os.linux.misc)
  • Re: VSS best practice for promoting code to production?
    ... might label it in VSS, then we will move it from our dev environment ... After the testers shake it out and determine that it's production ... The developer may label it again as a production ... The SysAdmin performs a get version from the developer's VSS. ...
    (microsoft.public.vstudio.sourcesafe)
  • Re: VSS best practice for promoting code to production?
    ... might label it in VSS, then we will move it from our dev environment ... After the testers shake it out and determine that it's production ... The developer may label it again as a production ... The SysAdmin performs a get version from the developer's VSS. ...
    (microsoft.public.vstudio.sourcesafe)
  • Re: VS.NET is too EXPENSIVE. Developers switching rapidly from it.
    ... > too much in light of the huge competition from Linux. ... If your company is considering a switch to Linux because you feel the cost ... of developer tools is too high then you may want to consider doing some more ... Visual Studio, as millions of developers do, then there is cost because ...
    (microsoft.public.vsnet.general)