Understanding Nothing

My “last updated” blogroll on the left hand side of the page is now much friendlier than before. I’ve made a fairly trivial changed my script so that to now use LWP::Simple‘s mirror() function, rather that it’s get() one. This uses the If-Modified-Since header to only fetch the body of people’s RSS feeds if they’ve changed. It should not only cut down on bandwidth usage, but also makes it much faster to update my blogroll, which was becoming quite slow, as this is all running on a fairly old machine.

Old George Orwell got it backward. Big Brother isn’t watching. He’s singing and dancing. He’s pulling rabbits out of a hat. Big Brother’s busy holding your attention every moment you’re awake. He’s making sure you’re always distracted. He’s making sure you’re fully absorbed. He’s making sure your imagination withers. Until it’s as useful as your appendix. He’s making sure your attention is always filled. And this being fed, it’s worse than being watched. With the world always filling you, no one has to worry about what’s in your mind. With everyone’s imagination atrophied, no one will ever be a threat to the world.

– Chuck Palahniuk, Lullaby

This article by Moser and Nierstrasz points out that those who use Object Technology (such as OO Frameworks, or other collections of reusable components) commonly report increased productivity. However individuals do not magically become more productive by using these. Rather they are just as productive as before, but at higher levels of abstraction. Frameworks do not make developers more productive, they just reduce the amount of work needing to be done!

They also spend some time discussing how Function Points are not a good measure for OO development, as they were never designed to fit a meta-model other than CRUD database structures, and OO models are completely different to this. They also point out that Function Points do not capture the effects of reuse; that is, the availability of frameworks or libraries that address parts of the requirements. Instead of measuring total functionality delivered, we should be measuring incremental functionality beyond that which is provided by framework components.

They therefore claim that a good software size estimation method:

• avoids historical “magic numbers”
• takes into account the availability of reusable components and frameworks
• captures arbitrary kinds of functional requirements
• expresses possible links between functional and structural requirements
• can be applied early in the development process

They then set forward “The System Meter” as an alternative to Function Points, which they claim is less predictive, but can be applied earlier in the process.

Karen asks why we, as software creators, haven’t yet learnt about the things that people were writing about more than 20 years ago. This ties neatly into an article I was reading yesterday in the April 1998 issue of Computer by Ware Myers.

Citing figures gathered by himself and Putnam, Myers claims that:

A reality that is not universally acknowledged is that the general capability of software organizations extends over a truly enormous range. The difference between the productivity of individual developers is in the order of 10 to 20 times. The difference between the capability of software development organizations is at least two orders of magnitude greater – 100 to 200 times.

As with most of these figures, the result is based on comparing extremities. However Myers also shows that, on their scale of 33 levels, “an organization now about 5 index numbers below the mean can increase its process productivity by a factor of 5-11 times by improving not to the very top, but to five index numbers above average.”

He offers some suggestions as to ways that organizations could improve, such as establishing the feasibility of a large development task beforehand, citing figures that 65% of 1 Million+ LOC systems are cancelled before completion, as are 50% of 500KLOC systems, and 25% of 100KLOC systems. As Myers says, these approaches “seem fairly obvious, but many software organizations manage to ignore them.”

So, what’s the hang up? Myers cites 5 main reasons why we never learn:

1. Psychological hurdles: we’re resistant to change. Developers in particular are usually keen to get to the “meat” of the task – the actual coding – and hate spending time on messy preliminaries.
2. We don’t know about better ways: Myers kindly suggests that developers might not have had the time to seek out new approaches, whereas I think most developers just don’t have the inclination. However, Myers points out that Business Systems projects see, on average, 10% productivity gains per year, so not keeping up can have quite a large cumulative effect.
3. We’re Gun-Shy: Lots of the “better ways” promoted in the past haven’t delivered on their supposed effectiveness. Why should be believe any other ways?
4. We’ve tried and failed: Even the valid “better ways” are usually not easy to implement; they take champions, time, investment and persistence.
5. We’re stifled economically: we may not have the resources to devote to long-range productivity efforts

Personally I agree more with Karen: programmers love to program. And we love to solve problems. Looking up someone else’s solution just isn’t as interesting or exciting as trying to work through it ourselves. And writing less code? There’s no way that someone else’s code would be as good as, or do all the things that mine would!

It seems to me that COBOL and other popular high-level procedural languages should be blamed for most of the current problems in programming. It is so easy to program in such languages that even novice programmers can write large programs – but the result is often poorly structured. With OO languages such as Smalltalk, programmers take pains to learn how to program, and the result is well-structured programs. Having programming approaches that can be used only by experts may be a good idea. Our past attitude of easy-going programming is a major cause of the present software crisis.

– Takaya Ishida, in Steve McConnell’s “The Best Influences on Software Engineers”, Software, 2000

There’s been a lot of debate on the Extreme Programming list recently about Tcl vs Java, mostly spurred by Dossy’s citation of the Jeff Hobbs quote: I’ve come to the realization that there are so many more Java jobs than Tcl jobs because it takes 10 Java programmers to do what I can do in Tcl. I’m only half-joking…

Interestingly I came across an article today in IEEE Computer, from Jan 1998, that compared the scripting languages (particularly Tcl) with the system languages (C, C++, Java et al). It covers most of the usual ground, but also includes an interesting chart of some applications that, for one reason or another, ended up being written in both types of languages:

Some of the reduction in effort is no doubt due to the TCL version usually being written second, but for at least one of the applications this wasn’t true. In many of the cases the TCL version also provided more functionality.

I was talking to Marty again recently about his anti-Java stance, and we were trying to think of ways in which different languages could be rated.

This of course reminded me to go back and check out Doug Bagley’s Great Language Shootout, which compares multiple languages’ speed and memory usage for doing the same task.

I’d previously helped optimise some of the Perl solutions, and last night I noticed that there were a few new tests from when I last looked at it. In partiuclar the results for the Matrix Multiplication test seemed slightly strange: Perl was much further down the list that I’d have expected.

The meat of the code seemed to be the function mmult:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

sub mmult {
    my ($rows, $cols, $m1, $m2) = @_;
    my @m3 = ();
    --$rows; --$cols;
    for my $i (0 .. $rows) {
        my @row = ();
        my $m1i = $m1->[$i];
        for my $j (0 .. $cols) {
            my $val = 0;
            for my $k (0 .. $cols) {
                $val += $m1i->[$k] * $m2->[$k]->[$j];
            }
            push(@row, $val);
        }
        push(@m3, \@row);
    }
    return(\@m3);
}

I played around for a while, and got about a 50% speedup with quite a nasty nested map approach:

1
2
3
4
5
6
7
8
9
10
11
12
13

sub mmult2 {
  my ($rows, $cols, $m1, $m2) = @_;
  --$rows; --$cols;
  my @m3 = ();
  for (0 .. $rows) {
    my $i = $_;
    push @m3, [ map {
      my $j = $_;
      sum map $m1->[$i]->[$_] * $m2->[$_]->[$j], 0..$cols;
    } 0 .. $cols ]
  }
  return \@m3;
}

I tried various approaches to turn the outer for() into a map as well, but my brain started hurting too much as it all got very messy.

And then I noticed that we were pushing to @m3 each time around a loop that counted from 0, and realised it would probably be much more efficient to just assign directly each time. So I replaced the push @m3, ... with $m3[$i] = ... , and performance shot up.

So I rolled back all the other changes I’d made, and just applied this straight through:

1
2
3
4
5
6
7
8
9
10
11

sub mmult3 {
  my ($rows, $cols, $m1, $m2) = @_;
  my $m3 = [];
  --$rows; --$cols;
  for my $i (0 .. $rows) {
    for my $j (0 .. $cols) {
      $m3->[$i][$j] += $m1->[$i][$_] * $m2->[$_][$j] for 0..$cols;
    }
  }
  return $m3;
}

I think this version is much neater, more idiomatic Perl, and also more understandable and maintainable than not just my optimised one, but the original as well. And it’s 3 times faster.

Optimising for speed doesn’t always mean trading off maintainability. Usually finding a better approach gets better results that micro-optimisations, and can end up producing an all-round better solution, not just a faster one.

Unfortunately Doug has stopped updating the Shootout pages, so perl will just have to languish 4 places lower on this test than it should be …

‘Welcome, all your Will-loving R3 fans, to the Ritz at Swindon, where tonight (drum roll), for your DELECTATION, for your GRATIFICATION, for your EDIFICATION, for your JOLLIFICATION, for your SHAKESPEARIFICATION, we will perform Will’s Richard III, for the audience, to the audience, BY THE AUDIENCE!’

There was a moment’s pause and then the curtains reopened, revealing Richard at the side of the stage. He limped up and down the boards, eyeing the audience malevolently past a particularly ugly prosthetic nose.

‘Ham!’ yelled someone at the back.

Richard opened his mouth to speak and the whole audience erupted in unison:

‘When is the winter of our discontent?’

‘Now,’ replied Richard with a cruel smile, ‘is the winter of our discontent…’.

A cheer went up to the chandeliers high in the ceiling. The play had begun. Richard III was one of those plays that could repeal the law of diminishing returns; it could be enjoyed over and over again.

‘… made glorious summer by this son of York,’ continued Richard, limping to the side of the stage. On the word ‘summer’ six hundred
people placed sunglasses on and looked up at an imaginary sun.

‘… to the lascivious pleasing of a lute …’ continued Richard, saying ‘lute’ loudly as several other members of the audience gave alternative suggestions.

‘I that am rudely stamp’d…’ muttered Richard, as the audience took its cue and stamped the group with a crash that reverberated around the auditorium.

The production was the only show at the Ritz; it was empty the rest of the week. Keen amateur thespians and Shakespeare fans would drive from all over the country to participate, and it was never anything but a full house. A few years back a French troupe had performed the play in French to rapturous applause; a troupe went to Sauvignon a few months later to repay the gesture.

‘… and that so lamely and unfashionable, that dogs bark at me …’

The audience barked loudly, making a noise like feeding time at the dogs’ home. Outside in the alley several cats new to the vicinity momentarily flinched, while more seasoned moggies looked at each other with a knowing smile.

They went on, the actors doing sterling work and the audience parrying with quips that ranged from the intelligent to the downright vulgar.

The play was the Garrick cut and lasted only about two and a half hours; at Bosworth fields most of the audience ended up on the stage as they helped re-enact the battle. Richard, Catesby and Richmond had to finish the play in the aisle as the battle raged about them. A pink pantomime horse appeared on cue when Richard offered to swap his kingdom for just such a beast, and the battle finally ended in the foyer…

— Jasper Fforde, The Eyre Affair.

This paper from Barry Boehm and Philip Papaccio in IEEE Transactions on Software Engineering in 1988 is most notable for the size of its  bibliography, which has 126 references! It also contains some interesting insight into why they think that software costs are important:

1. Costs are big and growing: therefore any percentage savings will also be big and growing
2. Many useful products are not being developed: therefore reducing costs will provide more time to attack this backlog
3. Understanding and controlling costs can give us better software, not just more software

The four main strategies they give for improving software productivity are:

1. Writing less code
2. Getting the best from people
3. Avoiding rework
4. Developing and using integrated project support environments

The most significant influence on software costs in the number of source instructions one chooses to program. This leads to cost-reduction strategies involving the use of 4GLs or reusable components to reduce the number of source instructions developed; the use of prototyping and other requirements analysis techniques to ensure that unnecessary functions are not developed and the use of already developed software products.

The next most significant influence by far is that of the selection, motivation, and management of the people involved in the software process. In particular, employing the best people possible is usually a bargain, because the productivity range for people usually is much wider than the range of people’s salaries.