killthemeeting

I observed in a previous entry that I found myself somewhat baffled by the software engineering process taken by some offshoring/outsourcing firms, and realized that one issue is that while these people were programmers, they weren't "geeks."  I realized then that there are actually a lot of things that are done differently by the "computer geek" set -- a group which tends to include all of the best developers I know.  Mainly, I've observed this in the differences between developers at my current employer (a large, traditional retailer) and my previous one (Microsoft.)

Geeks have different priorities than most people when it comes to software engineering jobs, and attracting and retaining them at a company can require some different strategies.  And they're worth attracting and maintaining, for two reasons: first, most of the really good developers fall into that category, and while you don't need all your developers to be superstars, it sure helps if some of them are; and two, because they don't care all that much about the money.

What does matter to them?  Several things:

• Autonomy.  Micromanagement drives them crazy.  This is a case where you must follow management-by-results, not management-by-tasks.  Figuring out how to do things is precisely what geeks enjoy about work -- tell them what you want, not how you want them to achieve it.  They'll figure something out, and be willing to go above and beyond what's required, because it's theirs.  Whereas if you give them a checklist, they'll do it haphazardly, because they're not invested in it.
  
• Isolation.  Geeks, all told, are not very social.  They do their best work when left alone.  The cubicle is a horrible environment, giving you all the obstacles to collaboration of offices but without any of the privacy.  Offices are ideal for most development work, the only exception being the early stages wherein there's a lot more collaboration and brainstorming than actual coding.  Actual coding needs extended, uninterrupted quiet time (well, sometimes it's not quiet at all if you count music, but the sounds are chosen.)  Geeks coding get into the "zone" -- a 5-minute interruption can and will cost you an hour of productivity.
• Technology.  Geeks want to be on the cutting edge.  You're not going to retain one for a project writing Yet Another Database Front-End unless you've got a truly amazing work environment (or seriously overpay them for work that frankly doesn't require superstar developers.)  More interesting projects often mean more than higher-paying projects.  In addition, it's worth investing in the technology they'll use every day.  Sure, they may not really "need" a $4,000 dev workstation with two LCD monitors... but they'll be more productive with one, be happier working on it, and it'll do more to retain them than you would from a comparably-sized raise.  Ever having to wait on substandard technology to keep up with them is irritating.
  

Most importantly of all, though, geeks despise "politics," where by politics I mean any situation in which interpersonal considerations outweigh technical considerations.  They have no patience at all for things like:

• Using an older, inferior, or simply less appropriate tool (e.g. programming language, web framework) because "the boss likes it," "we've always done it that way," or "we're a [insert product here] shop."  They need technical reasons for using a technology, not somebody's feelings.
• Anything perceived as unfair.  While I said they don't care much about money, there is one situation in which they do care -- if they feel they're paid less than market value, or that someone else who's not as good as they are is paid more.  Trying to keep salaries secret helps not at all -- they for the most part don't understand why they should be kept secret, and thus will totally disregard any order to do so.   Of course, the problem is that they're often unwilling or unable to see any non-technical factors in an employee's value, which sometimes do play a part in compensation.
  
• Fiefdoms and silos.  Geeks want to get things done.  And they don't care overmuch who does them -- when engineering solutions, they'll totally ignore interdepartmental boundaries.  This isn't a bad thing; however, managers often think it's a bad thing, since they want their team to get the credit for it.  What these managers fail to take into account is that trying to get the credit for it results in not just an inferior product but also unhappy developers.

Though I'm talking primarily about work here, these characteristics do extend outside of work, too, particularly the intolerance for personal considerations outweighing technical (or whatever they perceive as "rational" or "logical" considerations.)  Geeks don't see the point of playing a game if they can't play to win -- it's not that they care overmuch about winning, it's that the game has a framework of rules, and that framework should be complete.  I think this is one thing that makes geeks thought of as antisocial -- they don't take people's feelings into account when doing things, because those don't fit into the rational, logical, predictable framework they like.  I think that how "normal-seeming" a geek is depends largely on how willing they are to sublimate this impulse in order to relate to other people.

Finally, when it comes to performance management, geeks need to be told, directly and clearly, how they're doing and what needs improvement, if anything.  Not being people-oriented, they probably can't read you.  They don't know if you're happy with them or not unless you tell them.  And they're certainly not going to ask.  While they deal extremely well with technical ambiguity -- they love to solve problems, so an incoherent mess from a technical perspective is just a challenge to overcome -- they don't deal well at all with ambiguity in other contexts.  Clear expectations and consistent feedback turn the job itself into a problem to be solved, which makes it much more satisfying to them.

I can't help but think there's probably some correlation between what I've observed as the "software engineering geek" personality and some MBTI or enneagram types.  It's probably not an exact mapping, but it sure is something that comes up a lot -- I can pretty easily classify most of the developers I've worked with into "geek" and "non-geek" if I try. 

Posted by Grant at 09:10 PM | Permalink | Comments (0) | TrackBacks (0)

If you work in a sotfware development organization, you've probably heard a lot about "alternative" software development and project management methodologies, such as Agile, SCRUM, Extreme Programming (XP), Test-Driven Development, etc.  These are, of course, all alternatves to the traditional waterfall model (wonderfully parodied in the preceding link -- the conference linked to is, of course, not real.  I particularly like the session entitled "Pair Managing: Two Managers per Programmer.")

Most of my development experience came at Microsoft, which has its own software development life cycle (SDLC) and, for all its problems, still has a large number of very smart developers and a management corps consisting almost entirely of former coders.  As a result, I operated under the assumption that this SDLC was more or less typical for the industry, as it sort of vaguely lined up with the traditional waterfall SDLC.

And then I came to my current job.  Yes, I have found the IT shop that performs development on the unmodified waterfall model -- welcome to 1979.  The great majority of our software development work is outsourced to a contracting firm in India, and thus worked on overnight, largely out of contact with our management, and the amount of process involved is staggering.

On one recent project, the software development managers insisted on a 5-page requirements definition document, two management reviews of that document, a functional specification with four contributors, a peer review and a management review of that document, a detailed design document, a management review and sign-off of that document, and a test plan before development could begin on the code.

The code in question?  Five lines of SQL.

Yes, a 2-hour project took over a month.  Actually, it's not quite done yet, due to the repeated test cycles.  You might think all that documentation would have rendered bugs impossible, but if so, you'd be wrong.

Why on earth is so much process present?  Why does it take three documents and six meetings to write five lines of SQL?  There are twice as many pages of documentation as lines of code!  Well, having worked with the people involved on these documents, plus the development, and the testing, not just on this project but several others, I think I've figured out the purpose: process is being used as a substitute for competence.

The thing that's surprised me, though, is that process actually turns out to be a pretty good substitute for competence.  With enough steps, documents, design reviews, and test plans, I think that the proverbial 1,000 monkeys with typewriters really could produce a functional IT system.  The incredible amount of mutual reinforcement breaks the task down into such minute pieces that each piece is comprehensible and completable by anyone with even the slightest modicum of coding or testing ability.  It turns what is inherently a massively complex endeavor -- software engineering -- into little more than rote following of directions.  Each step is so long and involved as it must be performed in so much detail that the next step follows necessarily, without putting much thought into it.  The waterfall model enforces this level of detailing by making it nigh-impossible to change decisions made early on.  It also helps project management -- after years of this sort of development, the project managers know to a pretty good degree of accuracy how long each minute task will take, and can thus do a pretty good job coming up with a (shockingly long) timeline for a project in any stage of development.

The problem with this model, though, is that anyone who is halfway competent finds himself spending more time on process than on actual, productive development activity.  Everything is drawn out over a huge period of time.  I think this is the main thing that's been driving alternative methodologies like Agile and SCRUM -- the desire by skilled developers to sweep away all that process that's "in their way," and get rid of documentation and meetings.

This has led to the principles of the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

This is pretty much the complete opposite of the waterfall model, and developers often enjoy working in such a model quite a bit more.  (This said, it can be done badly, as discussed in Steve Yegge's blog here, though that post eventually turns into Google-worship.)  Good developers, on the whole, hate process, don't like writing documentation, have no concept of or interest in business concerns, and like to code by the seat of their pants anyway.  A methodology that says "what you want to do anyway, that's good!" will naturally get a lot of traction.  Nothing gets developers excited like telling them that they don't need to produce documentation, the code is the documentation.

However, I can see that as much as I hate the process-bound development process I work with here, an Agile methodology would be a total failure with these developers.  They are simply paralyzed by the slightest bit of uncertainty, entirely unwilling to just figure out for themselves what will work.  They entirely lack both the ability and the desire to experiment.  In short, while they're programmers, they're not geeks, and that idea still seems somewhat foreign to me -- when I think about developers, I still think about people who program for fun.  But these developers approach programming like it's on an assembly line, and they need to be told the right way to do everything before they're willing to touch it.

So if you're faced with a very involved, complicated process to do something, stop and consider why that process is there -- it's possible, likely even, that it's there to remove the responsibility of making decisions from some set of people.  Sometimes that's because someone higher up is (or was) a petty tyrant and doesn't care for decisions being made by anyone but himself -- in that case, the process may be ripe for a change.  But sometimes it's there because the people involved are unwilling or unable to act without it, and in that case you change it at your peril.  While a more agile process would be better for me, and is better for the development teams at Microsoft and Google, it's not necessarily better for everyone -- not everyone is a self-motivated geek.

Unfortunately for me, I don't think this is a process I can change here.  It turns out that outsourcing development to India is so much cheaper that even if it takes four times as long, it's still a net savings. 

Posted by Grant at 10:13 AM | Permalink | Comments (0) | TrackBacks (3)