The Programmer's Dilemma
raganwald.posterous.com
raganwald.posterous.com
Neither.
It was a failure of management...
Anyone who conducts a post-mortem with their people would be much better off simply looking in the mirror.
Where were the Vice President of Development and the Vice President of Marketing when things starting going bad? Things simply don't go wrong at the end of the project; there had to have been plenty of warning, if only someone was noticing.
Vice presidents do best by having their finger on the pulse of the things that are important and providing the right resources and leadership to enable both their people and processes to be successful. These two were in a time warp, reacting to failure instead of preparing for success.
The President needs to find a way to get the job done at the Vice President level. He's the one who needs either better people or better processes.
One day, he mentioned to her the process that we were doing.
And she laughed. She showed him the daily progress report. "What I did today? What I want to do tomorrow?" That her 3rd graders had to fill out everyday.
Are programmers adults that need to be self-managed + micro-managed like 3rd graders?
To be honest, it sounds just as insane—possibly more—that children have to do this kind of thing. There were fewer assessment exercises of this sort when I was in school, albeit appreciably more than my parents had to contend with. The main lesson I took away from them was to avoid, wherever possible, any job or career where I'd have to waste everyone's time pursuing such ridiculous make-work.
I worry that the more we force this stuff on children from an early age, the more they will take it to be the normal (de jure, not de facto) state of affairs rather than an aberration stemming from the awful tendency to value managerial gestures over productive work.
Poor schools have a lot of problems like poor materials (my brother's history text book had serious editing errors like "Abraham Lincoln was black.") and problems attracting good teachers. The problem seems to be bad enough that they, given the scores handed in, are even to the level of teaching for the tests. I don't see any real hope until parents are allowed to move the tuition money the state pays the schools to the school of their choice. Innovation is hard without choice.
That particular exercise is a way of practicing the connections between verbalization, logical reasoning about the future, and emotional desires. It sounds like an excellent way to help the top half of the IQ bell curve to work on projects bigger than will fit in their head overnight.
As to wasted time, it should not take more than a few minutes a day, a bargain compared to the time spent on the party indoctrination in history and social studies.
What I did today? -> Went to school. What I want to do tomorrow? -> Stay home and play nintendo.
The second question is not quite honest, more accurately "What BS can I feed my teacher?" I view these questions as a way of attacking integrity, lie or face the consequences. One might argue this teaches a valuable skill. But I find it hard to stomach.
If the simplest way to do so is a brief "Yesterday I built 90% of Foo, but hit problem Bar, today I plan to finish Foo and start implementing BaseWidget" then that's great.
Software processes, by definition, predefine the how. That kills the feedback loop and hinders projects from evolving. The same reason why waterfall is a mistake -- because it treats as fixed things that need to change -- applies to software processes in general. Software process is just waterfall at the project level.
Software projects are no less unique than software systems, but we would laugh out the door anyone who claimed to have a metadesign for all programs.
The paper reasons that following a strict process is unrealistic, but that it is still worth it to "fake" a process, by presenting your system to others as though you had followed it (for example through documentation and reports that mimic the waterfall process, presented to players such as the VP and Director of Marketing in the OP).
[1] http://www.idemployee.id.tue.nl/g.w.m.rauterberg/presentatio...
The most interesting thing is that this paper was published before I was born in 1986. Even so, everyone in my class (this was about 18 months ago) was in agreement that the paper was still valid. (Though there would be the reasonable argument that we weren't able to give informed opinions having yet to experience software engineering in the real world at that point)
nah. Waterfall survives because it lets business development share world-views with the customer.
Value working software and healthy collaboration with a process that routinely measures real progress and you'll never have to explain why you slipped 3 months since last week's status report.
Unless, of course, agile is that magic bullet Fred Brooks stopped looking for 25 years ago.
But FWIW, all I claim is that Agile does a poorer job of blaming people. The other stuff you're talking about is your point of view, which suggests to me that you are the right person to write the blog post.
I'm sorry, but measured against the number of times I've heard the phrase "Doing Agile Wrong", this sound disingenuous.
So for example, if I say "We tried Scrum, and it didn't work," and some evangelist tries to defend the project and says "You did it wrong," that is not the same as when I say, "We tried Scrum, our Team was fine, but the Product Owner did it wrong and that's why we failed."
I can't speak to what you've heard, but I certainly have heard a lot of the former, to the point where I reply to all such discussions with a pointer to the No True Scotsman fallacy:
"Agile works."
"No it doesn't, we tried it and failed."
"You did it wrong."
Compare and contrast to:
"Scotsmen are cheap bastards, Ne'er would you catch one standing a round."
"Hamish just bought me a dram of Lagavulin."
"Hamish may have Scots parents, but he lives in Toronto. No True Scotsman would stand a round."
If a project that uses Agile fails, the participants have no incentive to blame each other.
If a project that uses Waterfall fails, the participants have an incentive to blame each other.
Because Waterfall in the failure case gives people an incentive to blame each other, it's a poorer methodology than Agile.
If I haven't confused your argument, then the weakness is that you have not shown that Agile is a methodology in which people have no incentive (or ability) to blame each other if the project fails.
I might have confused the issue by trying to draw a distinction between blaming the process from the inside and from the outside. My claim is that it is much easier to blame a process if you aren't a participant in a failing process. For this reason, it is easier to evangelize a new process of any type as a consultant or as a new face than it is if you are an old hand who may be accused of having been a cause of previous failures.
I think this second point is true of any process.
What promises do developers and stakeholders make to each other in the methodology? How do you define "failure" and given that definition, how do you establish a causal relationship between an individual and the result?
2. The title gestures to that (notice that programmer and prisoner both have 3 syllables, even)
3. The article links straight to the SEP article on the prisoner's dilemma
http://plato.stanford.edu/entries/prisoner-dilemma/#StaHunPD
It could be that in some organizations, the rewards are such that a Stag Hunt is a better model.
Sorry for being unclear.
If mutual cooperation was the best outcome, there would be no dilemma.
[1]: http://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Strategy_f...
Maybe you don't care about "overall best outcome". Maybe you only care what happens to you, in which case I assume you would betray me. But in the face of rules that are going to screw the people no matter what, closing ranks causes the least overall harm -- assuming you have sufficient trust to pull that off in the absence of communication. (EDIT: For example, if you are both members of an organized crime syndicate or a resistance movement, the organization suffers the least overall loss/cost if it gives very strict orders that no one talks -- assuming the two people are of equal value to the organization. Even if you are not part of a larger organization, betrayal costs not only time served but trust of the person you betrayed. Depending upon the situation, one month in jail may be less of a loss than losing this person's trust.)
It's important to not bring too much real-world logic to the matter. What's being discussed is a certain payoff matrix; the "story" of the Prisoner's Dilemma is really just a way to try to wrap the non-math part of your brain around it, but the payoff matrix, exactly as written, is what is under discussion. The payoff matrix where there is a non-zero probability that they will both manage to skate is a different problem, one not necessarily less worthy of discussion, but one that is not the Prisoner's Dilemma any longer.
If you are interested in further discussion, you should google "Iterated Prisoner's Dilemma" for more fun, including stories about computer simulations of various strategies. Prisoner's Dilemma on its own isn't actually all that interesting, it's more useful as a framing device. Iterated Prisoner's Dilemma is actually interesting.
Peace.
It could very well be the red tape in the office, the politics, maneuvering, posturing, noisy programmer area, the tools programmers were given, time-wasting meetings, and thousands of other reasons.
My feeling is the blame falls on the guy claiming the problem space consists of "the programmer" or "the methodology". The manager figure delivering the bad news to the programmer is a kung fu master of politics and the art of war, he's trying to get blame placed on anywhere but himself.
Building software is very much in its infancy and many magnitudes harder than baking a cake.
And any manager who thinks just having the right ingredients, people and recipe will guarantee a good cake has never baked a cake, anyhow.