Why is software of such generally low quality?

Feb 17 06:53 UTC 2009

This discussion came up on the well.  I thought it might be interesting to
ask similar questions here.

Basically, the question is this: Why is software of such generally low
quality?

Thoughts?

response 2 of 28:

Feb 17 15:57 UTC 2009

Those are certainly good answers, and all true; what else?

I will submit that at least part of it is an attitude that holds software
separate from other engineering disciplines, and in many ways superior to
them.  It's an implied attitude that it's too difficult to get it right,
and that programmers should just be excused.  It's an acceptance and
defense of the status quo.

response 4 of 28:

Feb 18 02:24 UTC 2009

so they can actually accept their fate and defend/attack the wrong
decision.. out here, no one knows better and because the money is
flowing in, they see no reason to change their shady ways

response 6 of 28:

Feb 20 19:50 UTC 2009

Re the premise of resp:0 - There's wonderful software out there, and by
Sturgeon's Law, 90% of everything is crap.  Is software different from
anything else in this respect?

response 8 of 28:

Feb 27 15:20 UTC 2009

resp:6 There is some wonderful software, but even the good stuff is
bittle and prone to breaking.

response 10 of 28:

Mar 2 01:27 UTC 2009

memory: there are some good coding practices which somewhat make life
easier . like having functions less than one page ( 80 lines ). More
than that make it 2 functions. The idea being that human brain can
digest about one page of info at a time. or avoiding more than 3 levels
of indentation ( so its easier to understand and anyway in most cases of
business computing, having more  than 4 levels of indentation is
probably a sympton of bad design). even variable naming convention
helps.( longer and name in CAPS , the larger the scope of the variable )
 http://cm.bell-labs.com/cm/cs/tpop/  is a good book for those kind of
things 

My ex employer in India did have a kitchen. A cook used to arrive at
2030 and after that you can call him and he wil prepare and bring to
your desk stuff like omelette, nooodle , sandwich 

We had beds too ( a dormitory ) but for taking rest and not coding while
laying down. The female dorm was there since day 1 but the male one had
a unfortunate history. It was started cos once one guy worked very late
and at abou 5 am in the morn he was going home by bike and fell asleep
while riding !!! and had an accident.

>>Companies should spend time training people in-house.
I know for a certain that about 4-5 companys i know do that. Usually
while others are gathering project requirements. The team will have
informal training sessions so that each member is  at around same level
of expertise.

>>team leads should check to see if people know the languag
ideally it happens before that, the team is formed based on the
technical knowhow required. Sometimes they hold a test (written and
coding )  from the people in bench to select the team 

wonder if other grexers know what a bench is :) .. vivek i think will
know 

response 12 of 28:

Mar 2 07:47 UTC 2009

It wasn't such a great company actually. There were any things whoch I hated.
But the pantry with a cook and the dormitory was a big plus.
btw do you check your yahoo mail vivek ? I sent a mail not so long ago.

response 14 of 28:

Mar 2 09:21 UTC 2009

crap no, it's been ages since I did any mail checking (got a bad
cold+fever and chick worries :p ergo..) yeah I totally agree - once you
have a dorm+kitchen you are pretty much set for a somewhat relaxed life.
All my friends say that if they leave after 8AM they get rammed in
traffic, which means that unless they check-out by 4pm, they'll get hit
in traffic on the return trip.. that would imply staying at work till
10ish..
which is a really long stretch without food and water!

response 16 of 28:

Mar 2 10:18 UTC 2009

I think if you dont use it for 3 months it gets de-activated.

response 18 of 28:

Mar 4 06:58 UTC 2009

resp:9 and resp:10 Yes, long methods and deep indentation are two
symptoms of bad code.  These are what the agile folks like to call
"smells" in code; basically, hints that there's something suboptimal
about it.

I'd say that one screen-full is pushing an upper limit for the size
of a single method; I try to keep mine to ten or less lines of code,
and no more than two levels of indentation (not including the base
level for the method body), and preferably no more than one.  One
can use guard clauses here to help out.  E.g., instead of writing:

void foo() {
        if (x) {
                if (y) {
                        if (z) {
                                for (int i = 0; i < 10; i++) {
                                        dosomething();
                                }
                        }
                }
        }
}

instead write:

void
foo()
{
        if (!x)
                return;
        if (!y)
                return;
        if (!z)
                return;
        for (int i = 0; i < 10; i++)
                dosomething();
}

Or, even better:

void
foo()
{
        if (!x || !y || !z)
                return;
        for (int i = 0; i < 10; i++)
                dosomething();
}

Or, best:

void
fetch_network_data()
{
        if (network_is_ready())
                fetch_data_from_server();
}

void
fetch_data_from_server()
{
        for (int i = 0; i < NUMBER_DATA_PARTS; i++)
                fetch_next_part_from_server();
}

bool
network_is_ready()
{
        return (host_is_ready && connection_is_ready && server_is_ready);
}

You'll notice that the two-method version is slightly longer than the
original, but I would argue it's clearer and easier to follow.  In
particular, the name of the boolean function should be descriptive, and
the code should read like a story.

Similarly, classes should be rather short, and should read top down.
This makes it easy to keep the important parts fresh in your mind.

I won't go into more detail now.  Check out the book, "Clean Code" by
Robert C Martin for more; I disagree with much of what he says, but much
also has merit.  I believe he's right about short methods.

response 20 of 28:

Mar 4 15:23 UTC 2009

resp:19 In general I dislike globals for a variety of reasons, among
the biggest that they make it hard to test code and obscure it by
diffusing side effects throughout the program.  In general, one
should strive to limit scope as much as possible, with well-defined
accessors for state manipulation.  This makes it easy to figure out
where state changes.  For instance, private data members in an
object can only be modified by methods on that class (or, in C++,
by 'friend' classes), which makes it fairly easy to find where they
change.  (Unless, of course, you just have a bunch of methods to
'get' and 'set' the object's fields and you program extinsically,
in which case, you might as well just make the data public).

That said, hard laws in programming should be banned.  I'm not
married to the idea that globals are totally without merit.  Consider
some object that represents 'the standard debug stream' for a command
line program; where else would one put that?  As long as I can set
it up the way I want at the beginning of the program, I see no
reason not to expose it globally one or another.

With respect to the program snippet you mentioned, I would submit
that, if it were procedural-style code, there would be at least one
more global variable accessed in the function that reads the next
part from the server.

But, since I mentioned classes, it would not be unreasonable to
assume that those discrete functions would actually be methods in
a class operating on some object, and the global datum would likely
be fields in that class.  Certainly, that was my intent.

If one keeps one's classes short and well-defined, then the number
of fields tends to remain small and scoping problems are not so
much of an issue.  A good general principle here is that classes
should have one reason to change.  E.g., the representation of
something changes, or its behavior changes.  Anything else, and
your class is probably doing too much.

In "Clean Code", Robert C Martin makes the argument that methods
should read like stories, and each one should descend exactly one
level of abstraction from the one it is called from, and should
consist of statements that are all at approximately the same level
of abstraction.  Given good names, a method would then be read aloud
as, 'TO (name of method) WE (sequence of method statements).'  If
you put small methods like that in small classes, ordered so that
the calling method appears before the called method in the source
file, then each class reads like a story to comprise one discrete
chunk of data and logic in the program.  It also makes it fairly
easy to do things like dependency injection so that one can write
automated unit tests for the class.

I think that one *can* go overboard on it, but as a first order
approximation, it's not bad.

But really, that code was just meant to be a contrived example with
no relation to real code.  The idea in particular was to illustrate
how dividing things up into smaller methods with descriptive names
can result in clearer, more readable code.