Slashdot Mirror
Ask Slashdot: Have You Experienced Fear Driven Development?
nerdyalien writes: A few years back, I worked for a large-scale web development project in southeast Asia. Despite formally adopting Agile/Scrum, development was driven based on fear imposed by managers. Scott Hanselman defines Fear-Driven-Development as having three parts. 1) Organizational fear has "worried about making mistakes, breaking the build, or causing bugs that the organization increases focus on making paper, creating excessive process, and effectively standing in the way of writing code." 2) There's also fear of changing code, which comes from a complex, poorly-understood, or unmaintainable codebase. 3) The most common one is fear of losing your job, which can lead to developers checking in barely-functioning code and managers committing to a death march rather than admit failure. My project ran four times its initial estimation, and included horrendous 18-hour/day, 6 day/week crunches with pizza dinners. Is FDD here to stay?
It seems like you're extrapolating from that experience, to thinking "FDD" is a current trend. AFAIK it's not. A small number of dysfunctional shops like that has virtually always existed. I'm going to go out on a limb and guess that you've only been doing software development for a few years, so you're working from a limited sample size.
I have been in a few jobs where the managers were verbally and/or emotionally abusive. In both cases I left ASAP.
[2] is a very common problem, not just because of a badly written code-base, but mostly (IMHO) because of people not having the time to understand a complex piece of code. Ends up in 'nearly' the same code being written in a dozen different places. In my knowledge, it doesn't immediately screw things up, but, over time as the garbage accumulates leads to extremely interesting failure scenarios.
The only thing I will say is that emerging economies need Unions !
This machiavellian style of management is akin to slave labor.
If employees stay while working 18-hour/day, 6 day/week, it's because they are unable to find a better job. Thus, they have the best job they can find. So, there is no reason for the corporation to change their ways.
Therefore, the problem lies not in the current job but in the job offer. Thus, to solve it, the employee needs to find a way to get better offers:
- Develop new skills/ get new knowledge
- Switch city/country
- Self employment
Solutions based on forcing the current job to become individually better won't usually work as long as the change is local. (A local union, for example, will simply make external corporations more profitable and able to offer a better salary for the same job). Solutions based on forcing ALL corporations to become a better workplace are usually too slow from a personal PoV.
For me on the development side when I give an estimate with no accounting for problems along the way the answer is typically, great, here are your hours. When I get an estimate with a realistic estimate of problems that will pop up along the way I'm told, here is a quarter of what you asked for, see how far this gets you. Typically I tend to get less hassle if I ask for the minimum and then ask for more hours as needed (multiple times) with the reason why I need more hours (ex the same reasons I would have given for those hours up front).
Not to pile on here, but there is nothing new or recent about fear-driven projects of any kind, much less fear-driven IT projects. All you need to do is read some of the classic books on IT project management, including The Psychology of Computer Programming by Jerry Weinberg (1971), The Mythical Man-Month by Fred Brooks (1975), and Death March by Ed Yourdon (1997).
Back in the early 90s, I was chief software architect for a start-up developing a large, complex and novel commercial software product. After working long hours for years, we had missed our original release date and were struggling to come up with a new date that we could be sure of making. Top management (CEO, CFO) was considering carrot/stick "incentives" to "motivate" the engineering team to make a certain date; one of the senior developers stopped me in a hallway by the engineering offices and asked, "Don't they realize they're dealing with grown-ups back here?"
P.S. At the risk of sounding like an old fart, I remain appalled at the profound lack of familiarity among far too many IT industry practitioners of the essential books on software engineering and IT project management. As I have said ad infinitum and ad nauseum, not only do they keep re-inventing the wheel, they keep reinventing the flat tire.
Bruce F. Webster (brucefwebster.com)
From Thoreau, in Walden:
Based on this, it seems to me that every one of us who has ever been involved in development projects for any significant amount of time has encountered fear as a major force in one or more projects. For that matter, I'd say we've all encountered it as a force in many things we've been a part of.
For your security, this post has been encrypted with ROT-13, twice.