When a programmer is good,
He is very, very good,
But when he is bad,
He is horrid.
– Sackman, Erickson and Grant (1968)
Although the search for the holy grail of software development workflow is far from becoming a reality, that doesn’t mean we should give up and just accept today’s world of overblown budgets, missed deadlines and subquality products as inevitable; And although there is no single technological break through that promises to exercise all our software demons, there are a dozen good work going on right now that we can leverage to show promise of steady, if not magical, progress.
The key comparisons between world-class software organizations and the run-of-the-mill software organizations will be these:
- Staff cost: Salary and benefits
- Staff productivity
- Quality of the systems developed
And to the unaware, problems regarding low levels of software productivity are easily dismissed as the end result of programmer shortage. Rarely are programming environments, trainings, tools and workflows blamed.
I work for a software development company, and with other companies on the same industry before that, as a hands-on developer and I know first hand how it is to battle in the trenches day after day; I have heard my fill of horror stories as well as tiny miracles that are often taken for granted, seen enough obsolete work processes that are still in place because “if it ain’t broke why should we fix it?” and experienced technology fads like a girl changes clothing.
As a software development company, it is imperative that the day to day operations of the company should rely, if not heavily, on software intensive computer systems compared to doing them manually. This doesn’t only decrease the latency in conveying information but also reduce the number of errors committed. Gone are the days where a manager needs to roam the office and micromanage everyone in person. Measuring the productivity aspects of an organization is better accomplished with the aid of computers (using the proper metrics of course).
The major issues in our work are not so much as technical but sociological in nature and although most managers agree and are willing to concede the idea that they’ve got more people worries than technical worries, they rarely address and manage the issue as such.
So, what snake oil will I be selling today?
Improvement on peopleware. They are not those that are bitten by people – or are they werepeople? Anyway, people efforts should be directed to solve several related issues. And an old cliche says – You cannot solve anything until you admit (and accept) that you have a problem.
Hiring the best people.
Hiring the best people is pretty straighforward but that is often easier said than done. What is best anyway? Scientific evidence shows that the actual performance of programmers have no significant correlation with years of programming experience. So, scores on standard aptitude programming tests then? True, they may dominate early training and initial on-the-job experience, but that such skill is progressively transformed and displaced by more specialized skills with increasing experience.
Engaging in the ongoing training and education of existing staff.
Like in nature, programmers should constantly adapt to an ever changing technological front. No matter how good you are 10 years ago writing in this and that language, if you dont adapt you’ll be left behind with nothing more than glorified stories of your past to protect (or salvage) of what’s left with your bloated ego. Think of it and scale that across all developers in the company if no appropriate training and education is provided.
Motivating people for higher levels of performance.
Money isn’t always everything. Motivating people requires getting in touch with them. If you treat people as if they’re nothing more than replaceable code-converting machines that you keep from paycheck to paycheck then sooner, rather than later, they will vote with their feet and shop for the next coding gig they find. Giving proper credit is also a key. Gving a simple tap on the back for a job well done will really get you far. So stop giving undue credit on upper level managements just because they are the ones you like and are closer to you and look past those scruffy faces you see only at Christmas parties and other ceremonial company gatherings.
Developing performance management ideas to align personal goals with corporate goals
Tell your staff that a 2 month project iteration should be completed in 4 weeks and your staff will come up with the conclusion that (a) you are lying, (b) you are willing to let them abandon their personal lives including nights and weekends or (c) you are willing to compromise on quality just to meet the ridiculous deadline. Of course having a can-do attitude is essential especially when dealing with clients but knowing when to say no and set boundaries is as important.
Offering adequate working environment, with particular emphasis on adequate office facilities rather than pigsties in which most software engineers find themselves squating for 10 or so hours everyday.
Burdening engineers and programmers with subquality equipment and tools and expect them to produce top-notch products? You know how it is.
Placing more emphasis on creating and maintaining effective teams of people who can work together to create high quality software products.
One of the worst things you can do to decrease performance is to commit teamicide. You can’t force a team to group together just because you say so. You cant just say you, you and you are now part of a team to work on project X. Be teamlike! Sure developers can be herded together to work on a common project but effective teams are not created by edict.
But will management listen? Perhaps, perhaps not.
¾ + ¼ = 1 