Phred

Brighton UK

Geek

At last - someone who agrees with me that despite our perceived advances we are actually going backwards - instead of making systems (mainly software but some hardware too) faster, more efficient and easier to use we are making them more complicated, filling them with features that only a few users require, and consequently wiping out all the advances that are being made in the hardware.

I have just finished writing a SIMPLE web service - I was fortunate enough to have a reasonable environment to develop the server in but even so it took 7 pages of code to write the server and a test client and the transferred message (in XML) is 3 times bigger than the message transferred (following me?). How many opportunities do I have for introducing bugs in that amount of code? I can do almost the same thing as a stored procedure in a handful of lines (server and client!)

Now I'm not knocking the concept of XML; I’m all for standards of practice and interoperability - but by the time you've added WSDL, XSD etc. try having a look at some of the code - it's symptomatic of our “bloat” culture – and so we need more bloatware to interpret our open, easy to understand data. So we're not just bloating software; we're bloating network traffic too - as if we didn't have enough of that already.

It would be interesting to see if many people agree with me that we need a cut-down, simplified system to compete with today's leviathans - most of our users need little more from a network operating system than file/print sharing and email - need less than 10% of the features of Word or Excel - the story's the same with most products.

I fully understand some of the reasons behind some of the problems – in the old days (sad old git I am) we used to carefully hone storage allocation, array sizes, process loops etc. in order to reduce the amount of disk space, memory and execution time used – but that was when hardware was expensive (really expensive!) and labour was cheap – now these have reversed we tend to throw disk space, memory and processing power at a problem rather than use expensive staff resources – the problem here is that we not only miss out on the economies of these processes we also miss out on the inherent correction that took place during them – so we not only make things bigger we also make them buggier.

Look on the bright side – CPM runs like shale off a shovel on a P4 3GHz.