Sunday, December 1, 2013

Software development -- not management friendly

While we might not all agree what methodology works best (waterfall, agile, some combination of X-treme, etc.), we all know that software projects can be painful.

But they don't have to be. Management and marketing teams generally have a difficult time understanding the mind of the creative types -- be they graphic designers or software developers.

There's a trick that I employ that has worked over the years: manage programmers the way beekeepers domesticate bees. With the right application of beer, flexible hours, and input into a project, I've been able to get excellent Java/Objectve-C programs to swarm in place. And then harvest the honey they produce (satisfyingly workable applications).

Having a group of programmers who get along, who enjoy a challenge, who work as a team means building a small group that has esprit-de-corps. One team I cultivated matched junior devs willing to challenge each another, and an expert coder that the rest (including gem) looked up up to. Not for pair programming, but as a mentor and a high-level problem solver.

If the team gets too big (or, even, too productive), management and sales will take a big interest in what is going on in the developer department. But these are not robots working on the line to churn out, well, lines of code. The suit-wearing business types find that developers are unpredictable, odd-hours-keeping and anti-social, to boot. Planning, attending in-person meetings, working on schedules, producing reports -- these are anathema to creatives.

Seeing developers struggle with the team aspect of productivity in an organization can be painful. I've worked with software experts who could easily figure out the most effective way to write an algorithm to fulfill the defined requirements. But he was out-of-pocket when the team needed to design a solution that would not negatively impact a downstream system -- if the problem wasn't in his code, he had no ownership of it. And solutions frequently were inefficient or a long time coming.

Ultimately, that developer moved on, but I learned a valuable lesson -- team building helps everyone understand how to leverage each other's strength. Instead of a waste of intellectual capital, teams can find synergy through mutual understanding and -- best of all -- cooperation.


No comments:

Post a Comment