You are right -- must be a reason I buy cars and keep
them a long time (my 1980 Toyota 4x4 I bought new and now it has
historic vehicle plates) -- I think things should last. And if they
work, don't change them JUST for the sake of change. There is so much
to do that needs doing, re-doing things that work is madness. IMHO.
My software was written around 1980 -- it is a complete ERP system
(that talks to business partners, shipping companies, credit cards --
ALL with libxml2) -- it is STILL character based, still sells well
including many big-name companies and systems as large as 12,000
users. It uses a home-grown modified b-tree database. It is full of
added functionality since 1980, and absolutely zero technology
changes. There is a market for it -- I know it is not for everyone.
Essentially I get away with a very inexpensive hardware environment
(from the machine to network to backups to hard support), inexpensive
database, etc -- that does a LOT of work. It is a work horse, not a
pretty horse. I generally sell into industries with low gross margin
that need to handle comparatively large numbers of transactions (say
T-Shirt distributors where a shirt costs 1.35 and they make 3 cents --
it takes a LOT of transactions to do 100 million in sales and they
don't have a lot of margin to throw away on anything). Hence I stay
relevant in that niche. It is also why I like Unix (we use Linux, AIX,
and a lot of lesser-knowns) -- it is made to last a long time. I have
had customers with the same machine for 20 years. We just had a
customer who we thought was long dead that called after ... 20 years
... and wanted an upgrade. They had never had one (we were Y2K
compliant a long time ago). In their case our software worked too well
for too long and when they finally had a problem they became a paying
customer again. E On 5/7/2013 9:51 PM, Daniel Veillard wrote: On Mon, May 06, 2013 at 11:10:46AM -0700, Eric S. Eberhard wrote: [...]So they paid a nice young man to replace my server with a JAVA server (why do people feel compelled to replace working programs I'll never know -- guess the new IT person had to feel important). JAVA has built-in XML and TCP/IP and it was so "easy" to program, yack yack ... it also fell to it's knees at volumes that would be about 10,000 documents per day if it did not crash and burn when the load got high. That is less than 1/2% of what my libxml2 server can process. This, of course, led to AIX trashing and the IT guy wanted a room full of Linux boxes with server load balancing and all kinds of things. Fortunately sanity prevailed and the new IT guys is gone. The cheap little AIX box purrs doing all that work (and running the order desk, inventory, warehouse, shipping, credit, accounting -- all in real time all on one little box) ...Well I'm sure you too got similar story 20 years ago but with ASM or FORTRAN instead of C, some kind of mainframe instead of AIX, etc :-) . What we wrote will be obsolete sometimes. My own personal goal when I code is make sure the code will stay around for long, mothing depresses me as much as my code going to the trash (which happened a few times, and one of the reason why I do only Open Source code). But admitedly this is against a global economic trend, stuff is being designed to be wasted, replaced unresonably soon, and unfortunately that's true for code too even if it's so damn hard to get out and running. That's why I actually love Linux, there is no constraints put into the code to make it suitable only to a timeframe, a platform, or any specific use. Sorry for going from the anecdotic to philosophic, but that thread was already diverging :-) Daniel -- Eric S. Eberhard VICS 2933 W Middle Verde Road Camp Verde, AZ 86322 928-567-3727 work 928-301-7537 cell http://www.vicsmba.com/index.html (our work) http://www.vicsmba.com/ourpics/index.html (fun pictures) |