At our dev meeting last week, we decided to talk about the goals for Q2. Yes, it's already Q2 and yes, you generally have your quarterly goals set out before you actually start on the quarter. But code happens, and late goals are better than no goals at all.
We started brainstorming specific goals for the quarter. There were the usual suspects: refactor the ageing DAO layer, maybe replace the error handler that catches exceptions, then throws them into a black hole without any further reporting, and a team building exercise to San Francisco.
There were also a couple a touchy-feely issues: perhaps we should develop a development team mission statement that clearly identifies who we are, how we code, and why we code. Perhaps we should document the sprawling database, and the actually get the meaning of the more obscure column names (the meaning p_has_itern_pparker just isn't jumping out at us).
After we brainstormed a list, we divided them into the four quadrants made so famous by the book The Seven Habits of Highly Effective People (None Of Which Are In This Room Apparently). Each goal was either in the first quadrant (Important and Urgent), the second quadrant (Important, Not Urgent), the third quadrant (Urgent, Not Important) or the fourth quadrant (Not Urgent of Important).
As it turns out, every single task related to improving code, fixing bugs was considered either Important and Urgent, or just Important. Everything else was considered Unimportant.
I think this is the biggest trap development teams fall into. If it isn't a measurable improvement to the code base, then it isn't as important. That's why so few development teams have anything more than just an organized task management system.
This is why Red Mine is so popular these days. It excels at managing tasks, and, even more important, excels at managing busywork. Exhibit A: the wiki. I have yet to find a Red Mine wiki that wasn't built like a slum in Rio. Navigating a Red Mine wiki is a lot like trying to trace the Amazon back to its source. Some links take you down rabbit holes. Some links take you to a suddenly unexpected table of contents. The only thing Red Mine seems to guarantee is that it will capture your information forever, and hide it from everyone else, lest they try to actually understand it or, worse, fix it.
How many dev teams have organised architectural documents? Few. How many have several dozen incomplete pages, littered with printouts of sql statements, and half-finished tables describing what the columns do? A few more. How many have nothing? The rest.
How many dev teams have mission statements, or at least a organised -- there's that word again -- statement of why the dev team adheres to a set of common principles? Practically none. Is it necessary? Of course. You may be able to function with it, but you're highly unlikely to function at an elite level without it.
If the only thing important is reducing the bug count, improving the code execution, and completing your tasks, the dev team is nothing that an artificially intelligent code writing routing (patent pending) couldn't do. Thank god we don't have artificially intelligent code writing systems. But we do have overseas developers, and they work for a third of what you cost. You better be three times as productive if your only a code monkey.
In the end, it was decided that the number one priority of the team, for the entire quarter, was to reduct the time it takes to enter a ticket in Red Mine, and move the status from New all the way through to Complete. So there you have it. We have our priorities in complete order.
No comments:
Post a Comment