Collaborative decision-making in commercial software projects is liable to lead technical teams awry. Heretical as this may sound – and before the mob of inclusive development zealots cast their collective stones – please allow us one moment to explain our point of view, based as it is on our own experiences.
Creating complex software systems is a game of tradeoffs. To use an automotive analogy, you can’t design a car with the performance of a Ferrari and the hauling power of a Chevy truck for the price of a Honda Civic – you have to strike a balance. Likewise with software development: technical decisions call for technical tradeoffs.
Collaboration provides valuable perspectives and innovative insights into technical problems, but when it’s time for big decisions, the best you get is a compromise, which may not be the right decision. Although collaborative tools and best practices make it easier for people to work together, they fall short of addressing the individual and social factors that each person brings to the table. Suggestions made by team members may be influenced by personal preferences, experiences, and agendas: job security, resistance to change, procrastination, ambition, competitiveness, groupthink, insecurity, showiness, politics and more.
A true techie is a complex creature – part scientist, part artist – for whom software development is a calling, a passion, a way of life. It’s little wonder then that they tend to bring more baggage than most to the table. We’ve dealt with countless examples of pride in job ownership that have stretched the bounds of reason. In one instance, persuading the party in question to relinquish their code for the sake of stability, scalability and all the rest of it was akin to asking them to sacrifice their firstborn, so we gave up, against our better judgment. We watched the entire team wasting valuable time adapting to this doomed branch of the evolutionary code tree only to make someone else feel good. A few weeks later, when the dust had settled, it became apparent to everyone that we’d reached a dead-end; we had to throw out months of hard work and start from scratch.
At the other extreme, the desire to incorporate every single item of new technology that comes along can result in the creation of Frankenstein monsters, prone to crash and burn at any moment. This gives the ultimate thrill to the business side: it’s cool to be on the cutting edge, as long as you don’t fall off. When you’re trying to design software to be as lean as possible, the indiscriminate addition of new technologies is unlikely to do you any favors. And worse still, unproven software can conflict with existing pieces and lead to more serious problems.
To sum up, too much democracy can result in consensus-based decision making that is detrimental to the rapid development of scalable commercial systems. In our experience, having one person taking ultimate responsibility significantly speeds up the decision making process, reduces the risk of analysis paralysis, and allows decision making to remain consistent with the company’s central vision. The individual responsible also has the power of veto on questions of adopting new technologies or abandoning ideas that obviously have no hope of getting off the ground.
The person taking on these responsibilities must be inclusive; they must set expectations clearly within the team and be able to tap into the members’ knowledge and expertise, which they should choose and use on its merit. The individual should provide encouragement and overall guidance rather than finely-tuned micro management, acting as a catalyst and a conduit for the flow of ideas and swift decisions. We never said it would be easy!
Although collaborative decision making can and does work well in a number of settings, we found that in the context of large commercial systems the ability to make fast consistent decisions stands an equal if not superior chance of yielding the desired results.
Creating complex software systems is a game of tradeoffs. To use an automotive analogy, you can’t design a car with the performance of a Ferrari and the hauling power of a Chevy truck for the price of a Honda Civic – you have to strike a balance. Likewise with software development: technical decisions call for technical tradeoffs.
Collaboration provides valuable perspectives and innovative insights into technical problems, but when it’s time for big decisions, the best you get is a compromise, which may not be the right decision. Although collaborative tools and best practices make it easier for people to work together, they fall short of addressing the individual and social factors that each person brings to the table. Suggestions made by team members may be influenced by personal preferences, experiences, and agendas: job security, resistance to change, procrastination, ambition, competitiveness, groupthink, insecurity, showiness, politics and more.
A true techie is a complex creature – part scientist, part artist – for whom software development is a calling, a passion, a way of life. It’s little wonder then that they tend to bring more baggage than most to the table. We’ve dealt with countless examples of pride in job ownership that have stretched the bounds of reason. In one instance, persuading the party in question to relinquish their code for the sake of stability, scalability and all the rest of it was akin to asking them to sacrifice their firstborn, so we gave up, against our better judgment. We watched the entire team wasting valuable time adapting to this doomed branch of the evolutionary code tree only to make someone else feel good. A few weeks later, when the dust had settled, it became apparent to everyone that we’d reached a dead-end; we had to throw out months of hard work and start from scratch.
At the other extreme, the desire to incorporate every single item of new technology that comes along can result in the creation of Frankenstein monsters, prone to crash and burn at any moment. This gives the ultimate thrill to the business side: it’s cool to be on the cutting edge, as long as you don’t fall off. When you’re trying to design software to be as lean as possible, the indiscriminate addition of new technologies is unlikely to do you any favors. And worse still, unproven software can conflict with existing pieces and lead to more serious problems.
To sum up, too much democracy can result in consensus-based decision making that is detrimental to the rapid development of scalable commercial systems. In our experience, having one person taking ultimate responsibility significantly speeds up the decision making process, reduces the risk of analysis paralysis, and allows decision making to remain consistent with the company’s central vision. The individual responsible also has the power of veto on questions of adopting new technologies or abandoning ideas that obviously have no hope of getting off the ground.
The person taking on these responsibilities must be inclusive; they must set expectations clearly within the team and be able to tap into the members’ knowledge and expertise, which they should choose and use on its merit. The individual should provide encouragement and overall guidance rather than finely-tuned micro management, acting as a catalyst and a conduit for the flow of ideas and swift decisions. We never said it would be easy!
Although collaborative decision making can and does work well in a number of settings, we found that in the context of large commercial systems the ability to make fast consistent decisions stands an equal if not superior chance of yielding the desired results.
No comments:
Post a Comment