Re: Poor-man's Catweasel

[mdj <mdj.mdj@gmail.com>]

On Feb 10, 8:03 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> mdj wrote:
> > On Feb 9, 5:39 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> >> mdj wrote:
> >>> On Feb 8, 8:00 am, Steven Hirsch <snhir...@gmail.com> wrote:
> >>>> It seems like every major application I install that's written in Java comes
> >>>> with its own huge discrete JRE.  That's almost a tacit admission of the lack
> >>>> of interoperability.  Anyone can write bad code, but there just seems to be a
> >>>> lot of it written in Java.  Probably a lot of good examples out there, but I
> >>>> just haven't run into much of them <shrug>.
> >>> It does tend to feel worse due the "payload size" of the JRE, but
> >>> really, most platforms are plagued by this problem. Vendors will
> >>> usually take the path of least resistance(tm), and simply bundle
> >>> dependencies as a part of their distribution.
> >>> A classic problem you do get in the Java world is this one: Vendor
> >>> writes app that depends on newer features that are not (yet) a part of
> >>> the standard runtime. When a new runtime comes along, the feature is
> >>> often folded in, but teams don't typically get the time to rationalise
> >>> their codebase against the newer versions, resulting in duplication
> >>> and additional complexity.
> >>> It's almost universally true in the software industry that 'just
> >>> barely good enough' is seen as acceptable, since product lifetimes are
> >>> so short. I spend a lot of time trying to convince phb's that the
> >>> 'technical debt' incurred by taking the shortest path ends up being
> >>> paid for over and again for each iteration, and there are real
> >>> benefits to be reaped from cleaning it up.
> >> As I used to say, "quick and dirty" is never quick but always dirty.
> >> ;-)
>
> > :-) I really like the middle ground. If you engineer everything you
> > system will be, well, over engineered ;-)
>
> > Alternatively, take some of the time you 'get' by being a bit dirty,
> > and spend it refactoring the things that need it (using the 20-20 of
> > hindsight). This works pretty well, assuming your engineers don't
> > spend the time posting to Usenet ...
>
> I agree, "virtue stands in the middle".  My saying was a counterbalance
> against going too far Q&D.
>
> The counterbalances on the other side are "the perfect is the enemy of
> the good", and "good enough is good enough".  ;-)
>
> But I still find myself "tuning comments" from time to time...  ;-)
>
> OCD seems to be endemic to engineers and programmers!

Absolutely! I myself have an acute case of automation disorder; I find
it almost impossible to do a task any more than three times without
finding a way to automate it :-)

This is probably why Emacs and I get along like two peas in a pod ...

Matt