Imagine that some for some feature you're working, it could be implemented in a number of different ways, each with some impact to maintainability, performance, reusability, and development effort. You probably have a strong sense for which path is best, having looked at the problem in detail, but it's not usually wise to do anything until others (e.g. managers, business owners, other developers, etc.) weigh in. Until the decision is made, however, your task is blocked...and the sprint deadline looms.

In these cases, your job is to pop this decision up to the right group of people and facilitate the best decision, quickly so you can get back to work implementing the feature. Pretty simple, right? Just schedule a meeting, present the evidence, make your cogent argument, and they're bound to see the light. Err...not always.

In my experiences, facilitating a big decision is one of the more precarious, but crucial, tasks of the enterprise developer. Even if you get the right people in the room to make the decision, the discussion is like walking a tight-rope - one wrong step and you fall into the pit of indecision, or worse the abyss of irrelevant pontification.

So what can we do, as developers, to facilitate good, collective decisions? One useful thing to consider a psychological phenomenon called decision fatigue, defined as:

"the deteriorating quality of decisions made by an individual, after a long session of decision making" (wikipedia)

On large enterprise projects, decision fatigue is (depressingly!) the standard mode of operating for many of us. On any given day, we all must navigate and make decisions on dozens of complex, confusing, and frustrating issues, and this all takes mental energy. The more choices we make, the more tired our brains get, and according to theory of decision fatigue, the more likely that we'll then make bad decisions, or defer the decision altogether (a decision in itself!)

Back to the original example then, how can you help the group not fall victim to decision fatigue, so they can come to a good decision and you can get back to your task? Here are a few strategies:

1. It's always best to schedule morning meetings for important decisions. In a recent study on parole hearings in Israeli prisons, it was found that judges gave out parole 70 percent of the time when appeals were heard in the morning, and only 10 percent of the time when they were heard in the afternoon. Essentially, after hours of listening to arguments, decision fatigue sets in, and judges would rather make no decision than the wrong decision. Anecdotelly, this seems right - how many afternoon meetings end in the insanely-frustrating: "let's schedule another meeting!" - i.e. decision deferred.

2. If decision fatigue is the result of making hard choices, then another answer is to make choices easier for the group. One way to do this is to limit the solution set. For example, a study discussed in the book The Paradox of Choice found that consumers were 10 times more likely to buy jam when they were presented with 6 flavors rather than 24 - in other words, too many options make decisions difficult. As developers, when presenting decisions to the team, it's important therefore to frame the decision in the most "cognitively fluent" way possible, identifying ahead of time the salient trade-offs and simplifying to a manageable set of possible solutions.

3. Lastly, if the first two tips don't work, bring some candy for the team. Seriously. In studies done by Roy F. Baumeister, it was shown that sugar (specifically glucose) can effectively rejuvenate the brain from its decision fatigue, improving self control and the quality of decisions. (Note that it's this effect that is partially responsible for the junk food you buy when grocery shopping on an empty stomach - your brain's out of fuel, and so it makes poor decisions.)

Obviously, there's plenty more to consider when helping a group come to a big decision, but being aware of decision fatigue might help. As always, let me know what you think! (and if you're interested in some of the research, here's a great starting point.)

You and three friends stumble upon a great idea for a tech start-up. Because you're all talented developers and there are no "business" people to constrain you, the only thing that separates you from monumental success is just building the darn application. (seriously, it's a great idea). So you decide to all sit in a room to brainstorm the initial architecture, then you'll divvy up the pieces and get started.

I've lived this scenario a handful times, and have seen it too many to count.

What you'd expect to happen is this: each developer will come to the table with a set of preferences on what the architecture should look like, based on their unique knowledge and experience. All of these individual preferences would then be melded together, and the resulting architecture would represent some sensible compromise or average of the pre-discussion opinions.

What actually happens, however, is the exact opposite. Instead of ideas being pushed toward some average, they get pushed to the extreme. Cutting edge technologies, patterns, and approaches are chosen over relatively stable ones, and before you know it, you're programming the system in Clojure using a NoSQL database built using Gant, none of which anyone has any experience with. Two months into development the team realizes that it spent most of its time learning the new technologies, and very little has been actually produced. At this point the "window" has been missed, and everyone goes back to their old lives.

Some of what's going on here is the law of group polarization:

"Members of a deliberationg group predictably move toward a more extreme point in the direction indicated by the members' predeliberation tendencies" (Sunstein)

This phenomenon has been consistently replicated in a number of studies: conservatives meeting with other conservatives form more conservative beliefs, liberals more liberal, racists more racist, and so on. It's why political parties hold conventions before elections, and why niche discussion boards on the internet end up going completely off the rails. Like-minded peoples' preferences push toward the extreme.

The cause of this phenomenon seem to be two-fold:

First, people want to be perceived favorably by others, and so once they hear what others think, they adjust their opinion accordingly, to fit in with the group. In terms of the original example, who wants to be the guy who suggests to write the new application in old, boring Java? Come on man!

Second, people will share evidence in support of their opinions, which will further influence others in that direction (in which they are already leaning anyway). Essentially, the argument pool will be limited to evidence on only one side, and so this preponderance of evidence will push everyone even further.

Back to software development, group polarization happens often, potentially any time some relatively homogeneous faction (e.g. developers, managers, business owners, etc.) meets in isolation and makes decisions without input from others. The antidote, as would be expected, is inviting diversity...which is one reason that Agile works so well, since it puts developers in the same room with business owners. Although there may be disagreements, the resulting decision is typically some compromise.

Anyway, I find it helpful to be on the lookout for group polarization. And if I ever do a start-up again, I may be that lame guy who suggests Java!

1. Don't check in code right before you go home

It's 6:00, the [wife|kid|girlfriend|dog] is expecting you home in 30 minutes, and you just finished a really simple change. There's no harm in just checking this code in now before you go, right? DON'T DO IT! I swear I have been burnt by this too many times to count. If the build breaks or some bug pops up, you won't be there to resolve it...and every minute it goes unresolved you'll be losing good will with your fellow developers and testers. Obviously I always run a local build before checking in, but now I go a step further and try to hold off on any check-in if it's within an hour of me going home - better safe than sorry!

2. Batch your questions

As a new developer (or developer new to a team), you'll have loads of questions. This is good. Don't keep these to yourself, however don't ask them one-by-one as they pop into your brain. Write them down on a list, and only when you can go no further, then ask the tech lead/analyst/business owner all of your questions in one batch. People are almost always happy to help, but if you can limit the interruptions, it's always appreciated.

3. Stop complaining!

Yes, the system you work on is insanely complex/convoluted, the business owners are totally irrational, and the development team dysfunctional. Still...don't complain. If enterprise software development was easy, businesses could (and would!) hire people a lot less smart than you, and pay a lot less money. The fact that things are frustrating just means that talented developers are needed, and that we make a good living. If things are so bad, then quit - there's always a market for good developers. Otherwise, do what you were paid to do: make things better!

4. Keep it Simple - Format Matters

We all know the virtues of writing clean, readable code, but we don't always apply this rule to the artifacts we produce: emails, documents, models, etc. Spending time tuning/formatting these other products not only makes our ideas easily digestable by others, but it makes our ideas more persuasive as well. The minute it takes to tune an email for the people reading it is well worth it.

5. Be Nice!

I'm not talking about "nice" in the traditional sense, but rather in a game-theoretic sense. Many development activities can be boiled down to simple prisoner's dilemma situations: e.g. if we all comment our code we're better off, but individually it's more rational to be a free-rider and just take advantage of everyone else's comments (which is why it's sometimes irrational to comment code. It's been found that many people naturally play a tit-for-tat strategy, meaning if everyone else is "nice", they'll be nice too, but when someone free rides, they'll follow suit. Given this, it's always good to play the nice strategy and help others (review code, unit test, etc.). As soon as you don't, others won't either, and your development team can quickly turn to an every-man-for-themselves.

The question is, then, how do you get started? What do you do on that first day? You've committed to completing all the tasks, so does it matter? Of course it does.

Two simple approaches are...

1. Start with the tasks that are most fun. "Investigating clustering" sounds interesting, so start with that! This makes for a more enjoyable sprint...at least for the first few days.

2. Knock off the low hanging fruit first, and get some quick gratification at the beginning of the Sprint. Just like some financial gurus say to pay off your lowest debts first, it's nice to build some confidence before you get to the tough stuff.

Honestly, I find it really tough not to use these strategies - I just naturally want to do the fun tasks or quick-wins first...but having lived through more than a few failed sprints, I've quickly learned better.

First, there are some tasks which other developers are depending on me for (e.g. "Upgrading GWT"), and so if I wait till the last few days to do this, I effectively hose my colleagues. Second, there are times when I don't finish all of my tasks (gasp!) - maybe I had to call in sick one day, or requirements shifted, etc. If I do the most fun tasks first, I may have left some high value tasks hanging.

So here are some more disciplined approaches:

3. Start with the task that has the most dependencies on it (either within my own task list or for other developers). This approach is the best for keeping you in the good graces of your team.

4. Find out from the business owners which tasks are the highest value and work from high value to low - that way if something doesn't get done, it will be less of a big deal. For example, the "Order Status" screen might be crucial to the business, but "Upgrading to GWT" is not as big a priority.

5. Dig into the task that is the most complex first, so you can identify and mitigate the biggest risks right away, and you'll have more time to address them during the sprint than if you waited to the end.

Now each of the last three approaches (which can be blended, of course), are significantly more disciplined than the first two, but there's still a problem...

Most developers (me included) typically like to work sequentially - complete a task, move on to the next one. I find this more gratifying (and less stressful), but not very effective. It's very possible that lingering within each of my tasks is some big gotcha, that needs time (i.e. calendar time, not hours of work) to be dealt with. For example, maybe there's some question about the "Order Status" screen that needs to be posed to a business owner, and that business owner is booked solid till Thursday. Or maybe investigating clustering requires the assistance of a sys admin, and he needs a week lead time. If I don't identify these dependencies early, I could easily put myself in a position where I can't complete my tasks.

Given this, I've found the most effective approach to starting the sprint is this...

6. On the first 2 days, take a spike through each of my tasks (similar to the XP concept), understand better the requirements, and pick out the tricky pieces that might require input from others. This may require writing some code, but not much. Once I have a good handle, at a conceptual level, of what each task entails, then I can use some blend of strategies 3, 4, and 5.

The biggest drawback to this approach is that on those first two days, I find myself barely burning any work down - because most of what I'm doing is asking questions and planning. After everything is in order though, I typically can roll smoothly through my work.

Anyway, what are your thoughts? How do you start your sprint?

For example, in any given hour, I could easily receive one more email from project manager, phone call from business owner, chat request from developer, one-on-one drop-in from architect, build failure notification, and bug submission. And every single one of these would result in the same thing: more work on my to do list. Now add these to my existing tasks for this sprint, and all I can say is "holy crap".

I'm sure it's no different for anyone else doing the enterprise development thing, so my question then is this: how the heck do you manage this all? Or more specifically, how do you remember all that you need to do? And at any given point in time, how do you know you're doing the highest priority thing?

Thinking on this a bit, I know there's probably not much I can do about the quantity or frequency of incoming to-dos - working in a team environment is just inherently chaotic and complex.

My main frustration then is really just that there are so many lists of to-dos for developers: bug tracking systems, project management tools, IDEs (e.g. TODO), post-it notes, etc. When I want to know what I have to do, I either have to consult each these multiple to-do "bins" or just try to keep it all in my brain (which just means I'm thrashing all day ).

Basically, what I really need is a single place to track all my development related to-dos (ala GTD).

For a long time, I tried to do this old-school: with a simple, paper notebook. Every time I identified something new to do, I'd write it down. And while this is great for visualizing the entire list...and there's nothing better than physically crossing something off...there were obvious short-comings: I didn't always have my notebook on me, I was constantly writing and re-copying lists, there was no way to search or prioritize items, and there was no notification feature (that I was aware of ;).

More recently, I moved everything to my smart phone into a program called ToDo Matrix (good, but kind of over- priced). This works better than paper (more structure, searchable, etc.), and I've been able to consolidate most of my to-dos into one master list, but I still have a problem with redundancy (i.e. some to-dos are in the Bug Tracker, some in Rally, etc....and I either have to make a duplicate to-do on my phone, or keep them where they are and just consult multiple lists).

So does anyone out there have a good strategy for ordering the chaos of a mere mortal enterprise software developer? How do you manage your to-dos?

It got me thinking about how in any field (whether it be software development or biology, finance, etc.) people have very finely developed intuitions about what is "right" or "wrong" - something that seems akin to moral judgement. This happens in software development without a doubt - people who have been in the field for a while can have very powerful, immediate, gut reactions to problems - they just know that a certain path is "right" or "wrong".

The question I'm kicking around is, in software development, how are our "moral" intuitions best formed - by rational deliberation (e.g. reading, observing, studying, listening) or personal experience (playing many roles, living in the trenches)? In other words, which route would lead to greater "moral wisdom" - more study or more lived experiences?

(This question is a lot like the kerfuffle about Justice Sotomayor's "wise latina" comments months back - is she more "wise", coming from a rough neighborhood in the Bronx, than someone who came from the upper-middle class 'burbs?)

My sense is that no amount of study or observation can make up for living in the trenches and feeling the pain of bad decisions (your own and others'!). I can read all day about why unit testing is great, but it doesn't sink in to the level of "moral intuition" until I live through an experience where there's a million lines of code, no unit tests, and so no clue as to whether your change broke something else or not.

Anyway, just a thought...

I may work on module A this iteration and you on module B, but next iteration I may work on B and you on C.

No developer has sole responsibility for any piece of the system, we all own it together. If I need to update some piece of the system to implement my assigned user story, I can do it, with the caveat that unit tests should pass and probably some quality check should be met (e.g. peer review, etc.).

In any non-trivially sized team, this is probably a necessity; the alternative model, strict ownership of code, will just yield unnecessary gridlock, turf-wars, and code ghettos as developers operate unchecked in their own silo, hording knowledge, and protecting the sanctity of their individual assets at the expense of the overall architecture.

And even knowing this, that individual code ownership isn't really feasible in an organization, I still think that when we accept the model of collective ownership, something important is lost: craftsmanship.

Sure, Agile advocates would argue that pride of ownership just extends to the work of the team rather than just that of the individual. To some degree this does exist, but it's not the same. When we have ownership of something, whether a design document, an API, or a UI screen, it's our reputation on the line, our creativity and execution that make it a success or failure. We make decisions on our own, quickly, without having to reach team consensus, for good or for ill, accepting the consequences. And when it does succeed, we derive a strong satisfaction from knowing that someone found value in what we alone designed and created. We helped make something better, easier, faster. The freedom of owning our work is what makes programming fun...and meaningful.

Without ownership, this satisfaction is muffled. When people collectively own everything, no one owns anything in particular. Collective ownership often means collective design, and so there's less investment in the overall success, because, hey, these aren't necessarily my ideas, they're the group's. And because everyone's a stakeholder in all the code, decisions are often made via sophistry and compromise, producing an end design that often looks more like a piece of legislation and less like a piece of craftsmanship.

It reminds me of a favorite quote of mine from Steinbeck in East of Eden:

I know, to argue against collective ownership in the era of wikipedia, social media, and open source is probably insane. Working collaboratively obviously can produce high quality results, and benefit the collaborator as well.

Even still, talking to colleagues and friends that do software development on teams, I see this unsatisfied need to own. Just about every programmer has dreams about their own side project, where he makes the decisions, where he is responsible. It's this freedom which most of us need, and which produces works of craftsmanship.