[OT] Was: totally satisfied :D

[H. S. Teoh]

On Tue, Sep 18, 2012 at 03:15:33AM +0200, Andrej Mitrovic wrote:
> On 9/18/12, Andrej Mitrovic <andrej.mitrovich at gmail.com> wrote:
> > On 9/18/12, Nick Sabalausky <SeeWebsiteToContactMe at semitwist.com> wrote:
> >> Heh. One thing I've learned about myself: I love to complain :) I
> >> don't like having things *to* complain about, but when I do...
> >
> > I love reading posts like these. Here's a recent one:
> > http://www.hanselman.com/blog/EverythingsBrokenAndNobodysUpset.aspx

+1. After having worked in the industry for over a decade, I'm becoming
increasingly cynical about the state of software today. And seeing it
"from the inside" as it were, I realize that it *can* be done better. We
have all the tools to make it better. A lot better. But it isn't.

For example, I've seen enterprise code that looks like it was written by
highschool dropouts. I've seen how said code survives for YEARS in spite
of the presence of a code review system, simply because nobody has the
time to devote to cleaning things up, or nobody cares to because it is
not rewarded. Employers want "positive" contributions -- new features,
glitzy GUIs, unreasonable customer feature requests, bloat deemed
necessary because the CTO coughed it up one morning after a sleepless
night, etc.. Nobody cares about cleaning up what's currently there 'cos
it doesn't give anything to the marketing types to sell, and it doesn't
have any immediate apparent benefits. The code review process is more
concerned about hot-ticket items like security fixes, blatant crashes,
or other such important issues like Yahoo messenger not working on the
corporate network.  Nobody cares about the thousands of little bits of
horribly, horribly wrong code, the effect of which isn't obvious because
it's been covered over with layer after layer of festering bandages.
And even if you *do* make the extra effort to clean things up, the next
person comes along and doesn't understand what was done before, and just
slobbers all over it (figuratively speaking), turning it into yet
another mess.

And the result? You get stupidities like strange inconsistencies in
software behaviour, bugs that can no longer be fixed 'cos things have
started depending on the buggy behaviour, etc.. An embedded system that
has THREE database engines 'cos the teams in charge of various parts of
the system don't talk to each other and/or refuse to consolidate on a
single DBMS, resulting in completely needless bloat (I mean, *three* SQL
engines on a single embedded system?! Really?!). Or an executable that
takes 50GB of memory to link... I made the mistake of attempting to
running two builds at the same time, both of which hit this executable
around the same time, which caused my PC to lock up for over an hour
(locked up for all practical purposes, that is; it was taking 5
*minutes* to respond to a single keystroke as the disk thrashed itself
to death. Just don't ask why responding to keystrokes depends on disk
I/O).  A large part of that laughably huge executable consists of
largely copy-n-pasted-n-modified cout<< statements that outputs HTML and
Javascript, and other such boilerplate code. It boggles the mind that a
saner, lighter-weight system had not been designed for the task.  It has
been like this for YEARS, and will likely remain so for the foreseeable
future.

Is it any surprise that most software today is crap?  Sometimes I fear
that if I introduce D to certain people, they will just proceed to
rewrite the same train wreck that is their current C++ code in D, except
now they have so many more ways to shoot themselves (and all of the
miserable people who will come after them) in the foot, several times
over.


> Btw who on earth develops set top box software? Granted I've only used
> two so far (since I switched ISPs and my triple-play service
> recently), but the software on it is such incredible garbage. How do
> they manage to create software for a specific device, while knowing
> all of its characteristics, that lags like hell? I'd really like to
> see the source code for that. How many cycles could they possibly
> waste to blit a pre-designed bitmap on the screen (like the main
> menu)?

They must have written the software in ActionScript or something. >:-)

Either that, or they have 3 SQL engines running on the set top box with
50GB of copy-n-pasted Javascript-outputting code (that gets piped to VM
running a VB version of IE5's rendering engine). :-P


T

-- 
LINUX = Lousy Interface for Nefarious Unix Xenophobes.