| Saturday, November 1, 2014 |  |
| The conversation of work |
 Being a computer programmer has been one of my main sources of income for the past more than 30 years. More than half of it freelance, doing projects for people. I've noticed an important difference between very successful projects and not so successful projects.
Is there anybody to have the conversation with? Software development is a type of knowledge work. Key parts of the work is to get to understand the problems at hand and inventing solutions for them. Because what needs to be done generally speaking isn't known in advance, it is being discovered along the way. Modern approaches to development, such as the Agile principles, take that into account by bringing all the stake holders together and engaging them in frequent conversation, and by progressing very incrementally. But many people still mistakenly think that software is something mechanical. You just need to specify clearly what you want, and then the programmers need to just go and code it. That was how it was generally perceived a few decades ago. Analysts would write the specs for what needed to be done, and then we just needed to apply enough programmer man-hours to implement it. It never worked well, because once the programmers came back with the work, 6 months or a year later, and it was shown to the people who asked for it, they usually would realize that it wasn't really want they wanted, and they'll ask for changes. And the analysts would revise the specs and the programmers went off and did the work again, and came back some months later. That used to be the idea, but it is ridiculously wasteful and ineffective, so the approach has mostly been abandoned. However, that doesn't necessarily mean that it is easy to persuade clients that they need to be engaged in the process. Sometimes it is a very hard sell. The most successful software projects I've done have involved a continuous conversation with some other people, often daily. That doesn't mean long meetings. Nowadays it means brief asynchronous instant messages, and occasional short face to face meetings. Doesn't have to be with everybody, but it should certainly include somebody who has a sense of what is needed, i.e. somebody who represents the interests of the end users. And, strangely, that's occasionally very hard to find, and it might make the project suffer greatly. Meaning, it will take a lot longer, be more costly, and most likely not deliver what really is needed. The problem is in part that complexity is hard to understand. Complexity is something dynamic and alive that can't be all understood in advance, but that has emerging properties, which might or might not be the desired ones. This is as compared to stuff that is merely complicated. If it is complicated it might well be possible to make a big assembly diagram and have somebody simply follow the instructions. That works with many things, like Ikea furniture, but not with others, like software. Or communication. You can't just outsource an organization's social media relations and expect that it will work well. There needs to be somebody home who participates in a process of finding what works. So, a note to myself: Face the issue up front. Don't accept a development project that the client isn't themselves taking part in. If they just want to tell you what they want and hear from you how long time it will take, walk the other way. [ Programming | 2014-11-01 17:33 | 8 comments | PermaLink ] More > |