Ruminations on The Development Process – Part 1More thoughts from The Dev Team
Ruminations on the development process – Part 1
Why I meet our clients
As I write this I’m sitting at the airport waiting for a flight to Toronto. I’m on my way to visit clients. I will be there for one day and then travel on to New York for more meetings. It’s not unusual in our industry for company representatives, like sales people, or training consultants to go and see clients. But the head of software development? A little less usual.
For me and the other developers in our team, taking these trips is important. They give us the chance to meet our users on a regular basis. Insight into what our users do, and want to do is essential to the way we design and develop the product we give them.
But working this way isn’t always the case. In many organizations there is one team that designs the product and decides how it should work. This team listens to sales, support teams and other sources, after which they come up with a plan. This plan is then translated into a product specification. Finally, the specs are handed over to the developers, who do their best to turn these specifications into a product.
With this many steps between the users and the developers it’s not surprising that IT products are often disconnected from the real issues experienced by the users.
So, why do IT projects seem to fail on delivering good products so often?
From the Bottom up
I think a very common problem is that IT projects are often treated in the same way as more industrial projects, with a top-down approach. A team of engineers or designers, with highly relevant knowledge, come up with a product plan. Then workers execute these plans to produce the product. In contrast, in the IT industry you’ll find that the process may be structured in the same way, but the distribution of knowledge and skills is not. Of course you need good management and project leaders, who help to organize the work. But for the most part they don’t have in-depth knowledge about software development. Naturally, the developers do. So in this case, the typical top-down approach doesn’t make so much sense. Unlike industrial projects, with IT projects the people who have the most relevant knowledge are at the bottom.
Design is difficult without context
One way of approaching the development process is to have a separate design team, who act as mediators between the users and the developers. In this case the role of the developer is to solely focus on executing the product specifications. I won’t say that this never works, but you have to have a really good design team that understands both the needs of the users and how to develop software. In my experience, this is very rare.
The devil is in the details
A product specification cannot possibly cover all the details that the developers need to consider. After all, a computer program is just a very detailed specification of what the program should do. In theory, if a specification contained all the details, it could be transformed into a computer program and you would not need any developers. Luckily for me, that’s not possible, yet.
All these small decisions, the ones that can’t be covered by the specification, are really important for the end result. If the developers understand how the product is going to be used, the solutions they develop are far better suited to the users’ needs.
If you’re still unsure of whether it really is necessary for us developers to meet our clients, look out for my post next month when I’ll be mentioning some examples of what happens when we don’t!