RSS
| 1 news articles tagged with death_march |
The Dangers of The Death March Mentality
by Dave Hoover. 
Posted in 2. The Long Road. Tagged with death_march.
This book is written for newcomers to software development, so when I blog about "The Death March Mentality", I'm looking at it through the lens of someone in the trenches, someone at the bottom of the hill. From that perspective, I believe that Death Marches are a destructive force in our industry. I'm referring to the destruction of the newcomer's passion and excitement for developing software. If this person allows himself to trudge through the long, seemingly un-ending hours of a poorly run project, this person is going to gradually associate the act of coding with pain. Once this association is in place, he is going begin to look for ways to alleviate that pain, which will likely mean finding ways to do less coding and more managing. When the newcomer eventually moves into management, they will, like most children who swear they will be different than their parents, very likely repeat the mistakes of their predecessors. This cycle is an enormous loss for our industry as anyone can attest who has witnessed the incredible power of the intersection of the passion of the newcomer with talent and a healthy team culture.
For the newcomer to want to Stay in the Trenches, he will need to Nurture his Passion. I acknowledge that it isn't fair to ask a 22 year old to stand up to his boss when he is told he has to work another 12 hour day, but this is essentially what I am prescribing. I want newcomers to software development to understand that working hard to deliver software does not need to hurt. I want newcomers to understand what Pete McBreen means when he says "Software development is meant to be fun. If it isn't, the process is wrong." If newcomers can protect and nurture their passion for development, I believe our industry's innovations will flourish and our talent shortage will gradually disappear.
Julie Baumler said
I think there is a huge misconception that the best way to program (or administer systems) is to work long hours. I'm more productive when I work less. And yes, there are some days where I am really in a groove and can and want to put in 12 or more effective hours of work, but those are generally followed by days where I'm only functional and effective for a few hours. And constant required long hours do make your job painful.
I do think that a lot of the reason so many new managers do no better than their predicessors is because of a lack of management training (and in many cases interest.) If management is just what you do because you a) want out of a technical roll or b) at some point it is the only (visible or common) way to progress in your career, chances are you aren't going to be very good at it.
shogun70 said
Fun's gotta be the wrong concept. The pay would be a lot less if you could guarantee it was fun.
If (on average) you don't have to do overtime, you're doing okay. Simple. Quantifiable. Sustainable.
Anything better than that is a bonus. Fun is a double-bonus.
Michael Hunger said
Of course it is difficult to stand up as a newcomer to an unfitting environment. But perhaps thats the best thing one can do. Either way - improving the environment or getting fired and looking for a better place to improve your craftmanship - its a win.
Regarding the work hours - I fully agree. It is surely a sign of proficient people to work less and achieve more. To focus on the real neccessities and remove waste is one of the most important lessons to learn. When looking at lean and comparing this to the ways most of us still work - there is much room for improvement (kind of downsizing). And if you work less you have more time for your family and for learning and practising. (See also Kents 8 hour workday in XP)
But getting so efficient is surely a part of becoming a journeyman.
I don't agree with Dave that it is the apprentice lone responsibility to create an environment suitable for improvement. The company should be very interested in this - and most are if you just ask them.
Back to Agile - you need to have slack to perform well as an agile team. Besides the buffering effect it also reduces the pressure and allows you to adapt much easier to changing requirements. And 100% (or more) utilization of anything is always a bad approach as every operations, production or development manager can tell you (I wonder why software developers have to be utilized at 120%).
Michael
Michael Hunger said
Regarding Death Marches :)
http://despair.com/quality.html
shogun70, I have to disagree. Fun is an ideal, but in my opinion, it's not a double-bonus. I suppose it depends on what makes you tick. To me, working side-by-side with a small team, learning new technologies, while creating software is naturally fun. There are certainly times in even the best circumstances when I need to grit my teeth, deal with difficult situations, or put in a long day here and there, but I believe that the act of developing software is fun when it is managed properly.
Michael, I'm not trying to say that no one else is responsible for creating an environment suitable for improvement, but I am saying that the apprentice should not hesistate to try to create this environment if his employer is not. I am trying to prevent newcomers from accepting the status quo, putting their heads down like everyone else, and muddling through their cubicle farms in isolation with locked-down internet connections preventing them from collaborating. Apprentices should actively seek out (or create) teams, organizations, and companies that will maximize their learning potential.
Michael Hunger said
Ok, there I agree wholeheartedly. There are many ways for anyone enthusiastic to create collaborative environments even within restricted zones.
What I find a bit difficult is all the responsibility the apprentice has to bear. If you look at your craftsman studio at obtiva (as far as I could get from your blog) there is a much more positive environment and the apprentices are welcomed and supported. Where should an apprentice draw its motivation from if there is a more hostile environment and all this responsibility?
Michael
Michael, that's a great question. I guess my answer would be found here.
Julie,
Often the only upward career path for programmers is into technical management. Now often, if you're on that path you've had time to learn something by going through senior programming / team leadership positions beforehand. So it doesn't automatically follow that because that may be your only visible path you're automatically going to be bad at it.
However a person making that progression can (and probably should) take an interest in the craft of managing technical people and management in general. There's always something new to learn in technical careers.