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.
Fear driven development leads to anger driven development. Anger driven development leads to hate driven development. Hate driven development leads to buffering (and security defects).
Those who do not learn from commit history are doomed to regress it.
Caveat: I speak as a developer, just recently I've been told I should be doing more project management / team leading / mentoring. Everytime I ask a developer how long a piece of code will take I get an answer that I know is ridiculously unrealistic. Most non-techie Project Managers would take a developers 'I can do that in an afternoon' at face value. Instead I've had to have long discussions with my guys so that they begin to think in a way that gives accurate estimates (i.e. accounting for a bit of 'I don't know why this isn't working' and accounting for the fact they may have to refactor a bits of code here and there to make it tidier, etc.). So, now that I'm been on the 'other side' I do understand how estimates can go haywire.
90% is a small number, right?
TFA talked about a company in South East Asia and I do have business dealings with companies from that region - and I can tell you that many companies from that region are indeed dysfunctional
They kinda adopt the Western approach of management, but then they add in their own cultural flavor, mainly based on race / religion / language background and when all those things got mixed up, what TFA mentioned wasn't even enough to scratch the surface of the true dysfunctional nature of the beasts down there
Muchas Gracias, Señor Edward Snowden !
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)
If employees stay while working 18-hour/day, 6 day/week, it's because they are unable to find a better job.
That's called blaming the victim.
The only thing worse than a Democrat is a Republican.