August 3, 2012

...Learn TDD with Codemanship

Back To Basics #5 - Communicating Is The Principal Activity

This is the fifth post in a series of ten attempting to outline basic principles for software developers, free of the usual marketing clutter that tends to bamboozle people who are new to all of this sort of thing.

Hello there.

Yes, I'm talking to you.

You and I are communicating. Communication turns out to be pretty fundamental to softwarre development. In fact, if we sit down and think it through (you are sitting down, right?), communication is actually what software development is all about.

It's possible to explain every activity in software development in terms of languages and communication.

The act of programming is itself a form of communication. As a programmer, you explain things to the computer in a language the computer can understand. Well, more accurately, you explain things to a compiler or an interpreter in a language you can understand - for example, C - and it in turn explains it to the computer in the machine's language.

But when you write a program, the compiler isn't the only target of your communication. Programs have to be read and understood by programmers, too. So, as well as learning how to write programs that make sense to machines, we have to write them so that they make sense to humans, too.

Writing programs that make sense to programmers turns out to be even more challenging than writing programs that make sense to computers. But there is a very good reason why we should make the effort to do so.

Various studies, like one conducted by Bell Labs and summarised in this publication, estimate the amount of time developers spend reading and understanding code at anywhere between 50-80%. Understanding code is actually where we spend most of our time.

We need to understand code so that we can change it, and change it will. When code fails to communicate clearly to programmers, that code becomes difficult to change. And, as we'll see, accomodating change is absolutely vital in software.

Apart from writing code that is easy to understand - and therefore to change - there are many other instances where our ability to communicate effectively has an impact on our ability to create good software and deliver value to our customers.

I'm going to focus on two examples that I believe are particularly important: communicating the design within the team, and communicating with our customers.

When developers work together on the same piece of software - or different pieces of connected software - there's a great deal of communication that needs to happen so that teams can coordinate their work into a coherent whole.

Collaborative design requires that developers don't just understand how their piece of the jigsaw works, but how it fits into a larger picture made up of everybody else's pieces. Teams tend to underestimate how much communication is needed to make this possible. Inexperienced teams (as well as experienced teams made up of people who should know better, of course) have a tendency to take their bit and then go off into their own little corner of the room and work in isolation.

This can lead to evils such as unnecessary duplication and software having multiple design styles, making it harder to understand. It's also entirely possible - and I've been unlucky enough to witness this a few times - to find out, when all the pieces are wired together, that the thing, as a whole, doesn't work. (Yet another example of how the high "interconnectedness" of software can bite us if we're not careful.)

It's therefore very important to try to ensure this doesn't happen. Over the years, we've found that various things help in this respect.

Most notably, we've found that it can be a very powerful aid to collaborative design to use pictures to describe our designs, because pictures are well-suited to explaining complicated things succinctly ( a picture speaks a thousand words) and can be displayed prominantly and drawn on whiteboards, making it easier for the team to build a shared understanding.

It's also a very good idea for teams to integrate their various different pieces very frequently, so we can catch misunderstandings much earlier when they're easier to fix.

Building a shared understanding with our customer is of critical importance. Especially as there's a yawning gap between the handwavy, whishy-washy, "it's sort of kind of" language human beings use day-to-day and the precise, computable language of machines that we must ultimately express our customer's requirements in.

Bridging this divide requires us to lead our customers on a journey from handwavy to precise. It's not easy. There's a reason why our customers aren't writing the code themselves.

Non-programmers have a problem understanding computable statements, because they lack the ability to think like a computer, on account of having had no experience as programmers. So we can't use the same kinds of computable specifications we'd tend to use among ourselves.

But there is a form of precision that we've discovered programmers and non-programmers are both comfortable with and can both readily understand - examples.

I might give you a vague statement like "a want a tall horse", and to firm up our shared understanding of what we mean by "tall", you could show me some horses and ask "Is this tall enough? Too tall? Too short?"

We can use specific examples to pin down a precise meaning, exploring the boundaries of things like "too tall", "tall enough" and "too short" and building a general model of "tallness" that could be expressed in a precise programming language.

It's also often the case that our customer doesn't know precisely what they mean, either, and so examples can be a powerful tool in their learning process. They might not know exactlyw aht they want, but they might know it when they see it.

There are many other examples of the underlying role communication plays in software development. See how many others you can think of.





Posted 5 years, 7 months ago on August 3, 2012