Improving Wetware

Because technology is never the issue

Software development as a scientific activity

Posted by Pete McBreen Mon, 23 Nov 2009 06:21:00 GMT

Given that I do not agree with the characterization of software development as software engineering, it was somewhat of a surprise to find that there are a lot of parallels between software development and science.

Debugging and testing are probably the most scientific activities, in that developers have to make guesses about what is happening and then devise experiments to prove those guesses wrong. Developers also have to make predictions about how the systems they are developing will behave and then defend those predictions against speculations made by uniformed observers and occasionally defend against misinformation conveyed by financially interested parties.

One conclusion I could make from this is that the politics of software development are very similar to the politics of science. Practitioners try to pretend that there is no politics involved as it is all perfectly rational and understandable, but because people are involved it is all about politics. As soon as we start making predictions, then how we interpret those possible futures has a big effect on the actions we might take. This then becomes the realm of politics and it is that part that many software developers forget about (and many scientists as well) - Politics Matters.

We probably could have saved ourselves , but we were too damned lazy to try very hard … and too damned cheap. – Kurt Vonnegut

To celebrate the politics of science I’ve included a graphic reminder in the sidebar that small changes over a long period can result in a very interesting future.

Improving Documentation

Posted by Pete McBreen Wed, 11 Nov 2009 15:48:00 GMT

Seen a few useful blogs on documentation recently.

Jacob Kaplan-Moss has a good look at how the Django culture does documentation.

I especially liked this

Auto-generated documentation is almost worthless. At best it’s a slightly improved version of simply browsing through the source, but most of the time it’s easier just to read the source than to navigate the bullshit that these autodoc tools produce.

My take is that it is possible to produce readable and useful documentation using Rdoc or Javadoc, it is just that most projects do no take the time to produce good documentation. In many cases of Rdoc generated documentation all that is there is the signature to the method and a link to that excerpt of the code… not very useful.

Uncle Bob on Test Driven Development

Posted by Pete McBreen Thu, 08 Oct 2009 18:28:00 GMT

Seems that there is still a lot of resistance to using TDD.

Uncle Bob explaining the role of TDD in developing Fitnesse makes for interesting reading.

The bottom line is that TDD is a_ design technique but should not be the _sole design technique. All the old design rules and skills still apply; and TDD is a powerful way to inform and augment them.

Artisans and Handmade Software

Posted by Pete McBreen Thu, 08 Oct 2009 05:09:00 GMT

Not much time to post recently, but have to note an interesting post about Software Artisans and Handmade Software

Had to smile at the thought the calling yourself a Software Artisan was pretentious. If they think that is pretentious what would they think about calling yourself a Software Craftsman?

Talk About Being Late To The Party

Posted by Pete McBreen Sat, 03 Oct 2009 14:23:00 GMT

Ivar Jacobsen has an interesting piece in Dr Dobbs - Why We Need a Theory for Software Engineering.

I’d have thought that 40 years after the initial NATO conferences on Software Engineering, someone would already have the theory well developed by now. Setting aside my bias for a while, teh article has some really good questions

Do we really know how to develop great software? The answer for many people is clearly yes. But do we know how to communicate and continuously improve the way that we develop software? Do we really understand the best way to communicate and share our knowledge?

Do we stand on quicksand or the shoulders of giants?

Have you ever taken the time to investigate a new method or practice only to find that it is just the re-branding and regurgitation of ideas that you have seen many times before?

Have you ever got frustrated that every new idea about software development seems to be at the expense and in aggressive competition with everything that has gone before?

Does it seem to you that following that latest software development trend has become more important than producing great software?

I sense a certain amount of frustration in these questions, because over the last 40+ years it sometimes seems that little progress has been made in our ability to reliably develop software. Admittedly my answer to these questions does not include the answer “Software Engineering”, but other than that I find I share the sentiment expressed in the article…

It is clear that we need to stop chasing after fads and easy answers that forever disappoint, and that we need to do it without discouraging innovation and the generation of new ideas. People need to stop constantly re-packaging and re-branding old ideas just for the sake of it. Instead they should focus on helping people understand how to build great software.

Cooper on Agile

Posted by Pete McBreen Wed, 23 Sep 2009 03:04:00 GMT

Alan Cooper on Agile

“I’ve long been an advocate of such technological-craftsman-self-determination. It’s just that I advocated it via the “interaction design” point of view. ”

Defending Software Craftsmanship

Posted by Pete McBreen Sun, 13 Sep 2009 03:23:00 GMT

Saw this a while back but forgot to link to it.

In Defense Of The Software Craftsmanship Concept by Alan Skorkin

What about simply writing clean, nice code and doing it quickly and well. While I would love to say that anyone can do it no matter how ‘old’ they are, I would be lying if I did. Any developer who has ever looked at code they themselves wrote 1, 2 or 3 years ago will tell you that this is one skill that you can hone and improve until the day you, errr – become a manager (don’t bite my head off, i am only kidding :)). The point is, having a skill that you can continue to improve for as long as you’re able is the very definition of craftsmanship.

Other than the subtle jibe at managers, a nice summary of software craftsmanship.

Masterpiece Engineering

Posted by Pete McBreen Sat, 05 Sep 2009 23:44:00 GMT

Stumbled across this paper from the 1969 NATO Software Engineering conference that indicates that even back then someone was thinking that maybe engineering was not the right metaphor for software development

Unlike the first conference, at which it was fully accepted that the term software engineering expressed a need rather than a reality, in Rome there was already a slight tendency to talk as if the subject already existed. And it became clear during the conference that the organizers had a hidden agenda, namely that of persuading NATO to fund the setting up of an International Software Engineering Institute. However things did not go according to their plan. The discussion sessions which were meant to provide evidence of strong and extensive support for this proposal were instead marked by considerable scepticism, and led one of the participants, Tom Simpson of IBM, to write a splendid short satire on ”Masterpiece Engineering”. –Brian Randell

Since then we have endured 40 years of people pushing the software engineering ideas on us, and in spite of all that projects still have major stresses.

Lecturing Birds on Flying

Posted by Pete McBreen Fri, 04 Sep 2009 02:40:00 GMT

Lecturing Birds on Flying is another take on Nassim Taleb’s Black Swan idea, and Pablo Triana does a good job of explaining that a lot of what was supposedly solid theory around financial modeling, is actually not applicable in the real world.

It turns out that most models make the assumption that the probabilities that apply in markets are normally distributed (where anything beyond a three sigma event should be exceedingly rare), is incorrect and that the probability distribution has very “fat tails”, where a twenty-five sigma event is not unheard of. This work complements Nassim’s black swan book by restating the ideas in a slightly different way and by being written after another event that demonstrates that the markets do not have normally distributed probabilities.

The applicability to software craftsmanship stands out for me in the way that the models try to ignore the effect that individuals have on the market. The assumption is made that the actions of individuals are all independent, when it is blindingly obvious that this is not the case. Yes, the assumptions might work if the market was made up of lots of small players, but that is not the case. The markets only have a few players of any significance, the trades of any of these make the markets move, the small players make the random day to day noise, but the big players are what cause the problems - the too big to fail kind of problems.

Software Engineering is too big to fail

To get a good software disaster, you need the big ideas from software engineering that can influence lots of people to make similar mistakes on a project. The average level of software development is abysmal, most projects only succeed to the extent that they have one or two talented or experienced developers who manage to overcome the overall lure of failure.

Software projects should be built around the outliers that happen to be talented or experienced enough to succeed, but even then the sponsors should only bet as much as they can afford to lose. Nobody knows how to make massive projects successful - other than throwing money at it until it is politically acceptable to call the result successful.

The issues in software are different than in finance, but in both cases the underlying model of how the field works is incorrect, and the consequences of this mismatch between model and reality are what causes things to crash and burn.

Which is better, an untested theory or not knowing?

Posted by Pete McBreen Thu, 03 Sep 2009 01:41:00 GMT

Sometimes it seems that it is very hard to admit to not knowing something. It is as if having a convincing tale to tell about something is more important than actually being correct.

Explanations are listened to

Unfortunately this is true even when the explanations are based on pure guesswork, and potentially have no grounding in reality.

Nobody quotes the people who do not know

Most media are interested in the quick soundbite that explains an event, they are not interested in anyone who says that the causes are complex, interrelated and not amenable to a quick fix.

Maybe the best methodology is None of the Above

Most of the methodologies I have seen appear to be just guesses about what might work, but they are presented as it they are the one true solution to all our software development problems. Some methodologies allow for experimentation and as such are partially admitting that they do not know for sure, but it is a rare event for practitioners of any methodology to admit that maybe alternate approaches may be more suitable for a project.

While not advocating a roll your own methodology approach, I do advocate admitting that we do not know what really works for software development projects. Sure we know a few ways to Crash and burn projects, but that is not the same as knowing how to make a project succeed.