Becoming a writer

You're reading this. That means my language must be - at least - bearable. I'm well aware that it will never be great. This is partly because English is not my native language. Now that will never change. Also, I lack talent. That won't change, either. What can change, and what has changed in the past years, is that I've become much better at producing reasonable stuff. And I'm faster, too.

When I press my team members to start getting good at it, they often say they are not so interested. They want to program, design, test - and so forth. I think that's a big mistake. If you want to become a great software maker, then your communication skills need to be great, too. That involves many many skills, and the ability to create good texts is one of them. It's not the least of them either. And (this must sound as music to Agile ears) it's re-usable! You'll find these skills useful in many parts of your work and life in general.

It is so important that I always press people to get on with it and do it. The complaint that you're not good at it won't hold: you were not good at writing programs either, years ago. How did you manage to become the programmer/designer/[your job here] you are today? Indeed, the usual way. Studying the art, and doing it - a lot.

So don't try to hide when a text is required from someone but take the opportunity to invest in yourself. "You're worth it".

More worries

I've talked about the necessities of someone worrying about the project before. What should be worried about? Well, that the project is a success ...? But what does that mean? The right things have to be made, and in time, with a certain amount of resources.

Finding out what those 'right' things are, that is a big thing - one of the main raison d'être's for Agile methods. What must be made, and what should it look like so to say.

One technique that helps the developer a lot is to imagine you are now the user. Give yourself a certain task and try to fulfill it. In a way, imagine you have a project that needs this new piece of software (that stuff you are now making). Gather the data and start producing results. Find out how hard it is to use your new stuff. That some things can't be done. Some parts are useless, other parts non-existing.

I call this (and I'm sure I'm not the first) putting on the user's cap. That helps you create a decent 'version 0' product. One that will not be pushed aside with disgust (at least, not immediately).

In some cases that's not it. There may be different types of users. Each with their own cap. Your stuff may be used by end-users and system administrators. Geologists and geophysicists. Managers and technical people. And so forth. Some projects call for imagining the needs of many different types of users. That's a lot of caps, and constant switching is often required.

To support all these roles you may be able to add options, or some extra tools. Sometimes, the roles are so different that you have to make separate programs or branches. Of course that will usually not mean you make different internal objects, just that you offer the services in varying ways. This is a big difference with waterfall analysis that already splits up the functionality from the start. That makes it almost impossible to later join the branches. In Object/Service-oriented environments the counterpart of this 'early split' is lurking. It's the tendency to offer everything as you implement it, rather than making tailor-made things for each of your user types.