On Feb 9, 5:39=A0pm, "Michael J. Mahon"  wrote:
> mdj wrote:
> > On Feb 8, 8:00 am, Steven Hirsch  wrote:
>
> >> It seems like every major application I install that's written in Java=
 comes
> >> with its own huge discrete JRE. =A0That's almost a tacit admission of =
the lack
> >> of interoperability. =A0Anyone can write bad code, but there just seem=
s to be a
> >> lot of it written in Java. =A0Probably a lot of good examples out ther=
e, but I
> >> just haven't run into much of them .
>
> > 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 ...

Matt
--- SBBSecho 2.12-Win32