The Balanced Analyst Programmer

• development
• management

I’ve been asking myself a question lately:

“What is it that makes some programmers more effective than others?  Not quicker, not more technically elegant or advanced, just more effective.”

I think it all comes down to balance – having a mix of skills that make you accessible to the business world whilst keeping a foot planted firmly in the realm of software development.  In a lot of large corporations these days the need for this balance is reduced (well at least it seems to be), as the analyst programmer has been broken apart into two distinct entities; that of the business analyst and the applications developer.  However, the company in which I work this is not the case, and my team of developers is engaged (through myself) directly by the business to design and deliver software solutions – be they large or small.

Displayed to the right is a diagram that attempts to capture some of the aspects I believe go into creating this balance.  Now I very much doubt that everyone will agree with the breakup, and I really welcome some input as to what people believe belongs in each of the quadrants (even as I write this I’m considering some modifications to the diagram).

One thing I would stress in all of this, is that I don’t have the expectation that everyone needs to be have coverage in each area to be useful.  However, if a programmer is weak in one particular area then by teaming them up with another individual (or more) then an appropriate balance can be achieved.  It is for this reason that for my team, I am thinking about moving to a model where work is allocated to small teams to design and deliver rather than any one individual.  This in turn should assist with growth of staff plus the amount of ownership they take over the task presented to them.

Obviously, there is nothing new with having people working together in teams.  Often, however, this is done for the purpose of delivering larger projects rather than just smaller day-to-day tasks.   Additionally, whilst I believe good managers will be able to form good partnerships in their teams by using “gut feel”, spending time to purposely evaluating team members on individual strengths and weaknesses to achieve balanced partnerships is very worthwhile.

At this stage I am not thinking of implementing pair programming as I guess I can’t see the benefit of having two people with one keyboard to cut code can improve productivity (even given there is an ongoing peer review and consultative process involved in the development process).  I will say, however, I am no guru on agile programming techniques so welcome discussion around how to make this process work, and to here others experiences around things like pair programming and associated techniques.