
The Programmer's Dilemma - raganwald
http://raganwald.posterous.com/the-programmers-dilemma-95099
======
edw519
Was this a failure of process or people?

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.

~~~
fleitz
Exactly, VP is the level at which you've crossed the rubicon and excuses no
longer matter. You're in it to win and if you don't it's your (the VP's)
fault.

------
wallflower
A colleague of mine - his wife was a 3rd grade teacher.

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?

~~~
ionfish
> 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.

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.

~~~
wallflower
Having graduated from grade school many decades before NCLB, I fear that
adults are irrevocably changing education for the worse. Test taking isn't
learning, yet it the main priority for many schools (especially poor ones).

~~~
protomyth
Its not like the colleges are any help here with the requirement to take the
SAT, PSAT, or ACT for college admission. A student who doesn't know how to
take a test isn't going to get the scholarships or even entrance to college.

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.

------
toddh
Don't play the game with people like these. That was the real problem. Once
their nature and character became evident, which it must have quite early,
there was no way to win. Leave and find a better game.

------
gruseom
The other day I suddenly realized why I dislike software processes so much.
It's because how you build a system and what the system is depend on each
other. Each needs to evolve as you learn more (and as the team changes).

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.

------
upthedale
Somewhat off topic, but I am reminded of a paper I had to critique a uni: "A
Rational Design Process: How and Why to Fake It" [1]

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...](http://www.idemployee.id.tue.nl/g.w.m.rauterberg/presentations/parnas-
clements-1986.pdf)

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)

~~~
softbuilder
I worked on a project for a large corporation where the manager running the
project did this. I thought he was insane until it became clear that the fake
process created an umbrella for the devs to self-organize under. It wasn't a
perfect project but it went better than it would have if the process had been
real.

------
noonespecial
I know it's just a story, but if I had managers like this, I'd be headed for
the door so fast, I'd trip over them.

------
dustingetz
"And this could be why Waterfall survives: It's the process that optimizes for
blaming other people."

nah. Waterfall survives because it lets business development share world-views
with the customer.

------
Androsynth
In the original prisoners dilemna, there was real consequences involved: 10-20
years in jail. Getting fired from waterfallcorp doesnt sound like the end of
the world. (Some might even consider it a good thing). Entertaining read
though.

------
mikebd
Amen Brother! My new internal customer just had a wonderful surprise as we are
adopting Agile. He asked if he needed to work through me to reorganize the
backlog for upcoming sprints. No - you own scope and timeline. Reorganize as
much as you like on items we have not yet begun as long as you respect the
total effort estimates per sprint.

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.

------
lcargill99
If you are playing poker and you don't know who the sucker is, you're it!

------
lyudmil
This feels like an argument on the wrong level of abstraction. Even if the
methodology is at fault, it seems silly to say "Waterfall is the problem."
That's simply too large of a point to make. You could say that you fell behind
during development and couldn't tell that you were falling behind, so the
problem snowballed. That's specific enough for people to discuss without
resorting to politics. Otherwise you're taking the organization's dysfunctions
head-on, which is a losing battle.

------
Tycho
You can see this sort of thing play out in every episode of the BBC's
Apprentice. The prevailing strategy is to blame the someone for messing up
their part of the task, rather than to accept that the strategy which everyone
agreed upon or which they were forced to adopt was the source of most of the
problems. Since they're FORCED to name someone to fire anyway, not doing so
from the start just makes them look indecisive or dishonest.

~~~
fleitz
This is why smart people study rhetoric. Everyone is at fault but the guy with
the best sounding answer wins.

------
spenrose
Now you need to write the followup, which shows how agile and Scrum are so
often used to shift power from the business people to the developers without
actually solving the underlying problems. (You'll have to edit parts of this
piece where you imply otherwise.)

Unless, of course, agile is that magic bullet Fred Brooks stopped looking for
25 years ago.

~~~
raganwald
Nothing in the way of a methodology stops underlying problems of a culture
that thinks careers are a zero-sum game and that actually delivering the
software is secondary to advancement.

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.

------
will_sargent
"Theory P methodologies like XP and Scrum constantly recalibrate expectations,
so if the result is dissapointing, you are left blaming the inelasticity of
space-time. An alternate version of this story had the protagonists choosing a
methodology for a risky project: Choosing Waterfall was defecting and choosing
Agile was coöperating."

I'm sorry, but measured against the number of times I've heard the phrase
"Doing Agile Wrong", this sound disingenuous.

~~~
raganwald
I've heard "Doing Agile Wrong" too, however I think what the post is talking
about is when the participants accuse each other of doing it wrong, which is
different than when an outsider says an entire project was done wrong.

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."

~~~
will_sargent
So if I'm reading this right:

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.

~~~
raganwald
My claim is that if a project that uses Agile fails, the participants still
have an incentive in dysfunctional cultures to blame each other, it's just
that the structure of Agile makes it harder to blame individuals. So I am not
claiming that A is better than W or W is better than A at shipping software, I
am claiming that W is better than A at blaming people for failures.

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.

~~~
will_sargent
Can you explain how the structure of Agile makes it harder to blame
individuals?

~~~
raganwald
Perhaps we could pick a methodology and then imagine a project that "fails."
Given this scenario, the challenge would be to find a way to blame the
participants for the failure.

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?

~~~
will_sargent
Well, the great thing about scrum planning is that you know exactly how long
it will take and who to hold accountable.

<http://marcin.floryan.pl/blog/2011/06/nightmare-agile>

------
o1iver
Sounds a little bit like the prisoner's dilemma...

~~~
briggsbio
Thanks for the insight Captain Obvious. Did you forget to eat your Wheaties
this morning?

~~~
younata
"Be civil. Don't say things you wouldn't say in a face to face conversation."
[1] There are many places for insulting others, HN is not one of those places.

[1] <http://ycombinator.com/newsguidelines.html>

------
maeon3
The problem here is that managers think that writing good software is like
baking a cake, if you have the right ingredients, the right process, the right
environment and the right people, then you are 99% likely to end up with a
satisfactory cake. This is absolutely not the case with building software.

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.

~~~
va_coder
I've been developing software for over 15 years and without question
communication and politics are just as important as technical skills. You have
to get key people on your side and you have to keep everybody up to date on
the status of the project.

