Sunday, June 23, 2013

Software development is such a new field?

Software 'engineering' is not such a new field anymore, is it? After all we have been writing software since the late forties – so our field is more than sixty years of age.

Strangely enough, I keep hearing the argument that this is such a young field of engineering and we "don't yet have the experience to make it an exact science."

Is that really true?
How about building planes? That's quite a new field as well, right? If we start the timeline with the Wright brothers, we would have to start in 1903 (if you'd want start with Otto Lilienthal I'll raise you a Babbage – and I would answer a DaVinci with a Leibnitz – or even a Pingala if I have to. So, just for the sake of the argument let's stick with powered flight and 1903). So the Boing 747 – which had it's inaugural flight in 1969 and is still in service with many airlines – was designed when the craft of building planes was roughly the same age as the craft of building software is today.

And I doubt that you would refrain from stepping aboard a Jumbo-Jet because it was designed at a time where "the field of aircraft development was still very young and the results where not always predictable."

So I think, we should put more emphasis on the things we already can do – let's not complain that our internet connections is slow on a transatlantic flight – let's be amazed that we do have an internet connection on a transatlantic flight!

And let's not complain that software development is not determinedly predictable but let's embrace all the techniques we do have to manage and navigate this uncertainty.

In essence: we do have the tools – we just have to use them!

BTW: When Tom Breur and I designed the hands-on lean and agile practices course we found that there are so many tried and proven practices even from our own hands-on experience that we had to actively limit the number of practices to make it a digestible sized course.

Sunday, June 09, 2013

What's in a name? (a.k.a. "I don't think that word means what you think it means")

Why is it so hard to get the challenges of software-development across to people who are not from "our field"?
To be quite honest: I don't know. But I do have an inkling about some of the more obvious points. One of them, that has been pointed out numerous times, is that we tried to compare software-development with production for a really long time - instead of comparing it with, well, development.
But let's not linger on that aspect - let's look at another one that has not been covered quite as well. Language and mental models. In most other fields the words and their physical representations are put to the test quite early - even if the words themselves may be ambiguous. No one would really try to use hazelnuts or walnuts and cross-bow bolts when a manual speaks of "nuts and bolts".

So, what's different in Software development? A lot! One of the main differences though is, that we don't work with concrete material (nuts and bolts) but with concepts - words representing things from the physical world. Or even worse: words representing things from the physical world that represent concepts that represent intangible things - like money or time.

But let's just focus on the words for a second - they can mean a lot of different things to different people. For example my grandmother has quite a different notion of the concept "button" than my godchild does, as I am sure you can imagine.

Or, as Lewis Carrol put it in "Through the looking Glass":

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.' 'The question is,' said Alice, 'whether you can make words mean so many different things.' 'The question is,' said Humpty Dumpty, 'which is to be master — that's all.'

And this is not only true for the concepts we use inside our craft but also for the concepts we employ to create, envision and define our products.
Let's just look at some examples...

And so forth...

So from my point of view one of the challenges we face is in the meaning we put in words and concepts and how much they can differ across organizations or even within a team.

What to do about it? Take the time to find your own meaning for the words, join industry groups to discuss those meanings and get a little bit better applying the concepts every day. And never rely on a word meaning what you think it means - always verify with the people with whom you're working, that you're talking about the same things - even if you use different words.

Shameless plug: And perhaps attend some trainings where you can experience some of the concepts behind some of the words first hand...