• "H. S. Teoh" <hsteoh quickfur.ath.cx> Aug 23 2013

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Fri, Aug 23, 2013 at 08:33:55AM +0200, PauloPinto wrote:
 On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
On Thu, Aug 22, 2013 at 10:10:36PM +0200, Ramon wrote:
[...]
Probably making myself new enemies I dare to say that gui, colourful
and generally graphics is the area of lowest quality code.




 All areas are bad, given the way software projects are managed.
 
 The consulting projects I work on, are for Fortune 500 companies,
 always with at least three development sites and some extent of
 off-shoring work.
 
 GUI, embedded, server, database, it doesn't matter. All code is
 crap given the amount of time, money and developer quality assigned
 to the projects.


You're right. All (enterprise) code is bad, 'cos the deadlines force you
to use a hack solution and do a slip-shod job, because otherwise you'd
be fired for continually failing to meet the deadline. And it's a
vicious cycle. The first wave of programmers are forced to write bad
code because of the unreasonable timeline, then the unfortunates who
inherit that code are put on the same unreasonable timeline and now they
have no time to understand the already-badly-written code, and so they
can only write worse code on top of that. A few more waves of
programmers after that, and the code is in such a sorry state that
nobody even cares anymore, 'cos any effort at improvement is futile.
Unless you're one of the braves who dare to junk the whole thing (or
more realistically, a particularly bad module) and rewrite it from
scratch. Of course, the new, better code only remains good for so long,
before it starts to deteriorate too.

But IME, the worst offender is still the GUI-related component. Why this
is so, I can't really say. But there's a definite pattern that anything
to do with the GUI component, or anything to do with javascript, tends
to devolve into a horrid mess faster than, say, database-related backend
code.


 Usually the top developers in the teams try to save the code, but
 there is only so much one can do, when the ratio between both classes
 of developers so big is as a way to make the projects profitable.
 
 So the few heroes that at the beginning of each project try to fix the
 situation, eventually give around the middle of the project.


Yeah, and it doesn't help when upper management shuffles people around
with no regard as to which projects they are most familiar with (and
therefore most productive in). We're just expendible pawns on their
chessboard, and if they see fit to sacrifice us to a sinking project for
the sake of winning one last sale before they ditch the project
outright, who are we to object? Or, you get the reputation that you're
one of the exceptional coders, and suddenly there's the expectation that
they can dump any project, no matter how badly written, and you'll be
able to fix it up in 2 days and deliver a shining, working product in 3.
Which, of course, necessitates last-ditch hacks and workarounds and lots
of untested code, 'cos there's no way anyone can physically accomplish
such feats in the amount of time given.


 The customers don't care as long as the software works as intended.


Yeah, and that's where it really sucks. People have come to expect that
software needs to reboot every other day, and that it's "normal" for a
large GUI app to crash every now and then. I wouldn't sit in a car that
randomly fails in the middle of the road every other day, much less buy
one, yet people would shell out gobs of cash for badly-written software.
I mean, yeah they will complain when it does crash, but they'll still
willingly shell out more money to pay for fixing what shouldn't have
happened in the first place.


[...]
LOL... totally sums up my sentiments w.r.t. GUI-dependent apps. :)

I saw through this façade decades ago when Windows 3.1 first came
out, and I've hated GUI-based OSes ever since. I stuck to DOS as long
as I could through win95 and win98, and then I learned about Linux
and I jumped ship and never looked back. But X11 isn't that much
better...  there are some pretty bloated X11 apps that crash twice a
day, too.


 Funny, I have a different experience.
 
 Before replacing my ZX Spectrum with a PC, I already knew Amiga and
 Atari ST systems. And IDEs on those environments as well.
 
 So I always favored GUI environments over CLI. For me, personally, the
 CLI is good when doing system administration, or programming related
 tasks that can benefit from the usual set of tricks with commands and
 pipes.
 
 For everything else nothing like keyboard+mouse and a nice GUI
 environment.
 
 Personal opinion, to each its own.



Yes, to each his own. :)  I still heavily prefer CLI-based apps, and I
still think many tasks aren't *inherently* graphical and therefore
doesn't need to be handled in a graphical way. There are tasks for which
GUIs are more appropriate, of course -- image/video editing, data
visualization, etc.. But for me, it's CLI by default, and GUI only when
necessary, whereas for most people, it's the other way round. *shrug*


On Fri, Aug 23, 2013 at 12:34:07PM +0200, Chris wrote:
 On Thursday, 22 August 2013 at 20:10:37 UTC, Ramon wrote:


 It's the "bolt-on" mentality that ruins things, which is partly due
 to deadlines. As one guy once said to me (after I had complained
 about a quick and dirty implementation) "We have the choice between
 doing it right and doing it right NOW!" Ain't no more to say.


Yeah, it's a number of factors that add up essentially to "we don't have
enough time to write this ourselves, but library X already kinda does
what we want, so let's use it! Besides, it looks cooler, so the customer
will like it better! Nevermind the fact that it's not really compatible
with the other libraries we're currently using, but who cares? As long
as the customer gets to see that we're on top of the latest hype,
they'll be more willing to forgive us of inherent bugs we don't know how
to fix. We can always just write workarounds to hide the problem anyway
-- it's faster than trying to fix the root cause. Just stick those  's
in front of every line in the PHP code, and the users won't even see the
errors! We'll just insert a while(true) loop in this thread somewhere so
it looks like the software is doing something useful afterwards, so they
won't even know it crashed!"


[...]
 And last but not least, a programmer can work for hours on end
 implementing a clever algorithm, using unit tests, component
 programming etc etc. Nobody will ever notice. If users see a button
 that when they press it the screen says "Hello User!", they are
 forever happy. What goes on under the hood is "boys and their toys".


Yeah, doing it "right" is rarely ever appreciated. I've had people tell
me, why do it the right way? I've already written it the wrong way and
it *appears* to work and nobody can tell the difference anyway, so who
cares?

Only once in a rare while, doing things right actually has visible
effects... like that one time when I rewrote a shell script that does
data analysis (a *shell script* that does data analysis!) in Perl,
resulting in a performance improvement from 2+ days to 2 minutes. (It
wasn't the language per se that made the huge difference, though it
helped -- it was the fact that the shell script used grep and awk in a
way that resulting in an O(n^2) algorithm, whereas the Perl script uses
an O(n) algorithm.)

But such occasions are rare.


T

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula: pi zz a. -- Wouter Verhelst