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.
I've seen plenty of "fear driven development" over the years, but the "fear" was usually on the part of incompetent employees who were afraid they'd be caught out as idiots and fired. They'd churn paperwork and documentation rather than touching a line of code, because if they broke something, their incompetence would become apparent.
Fear is the mind killer.
But if you're afraid to do your job, it's because you have a problem with confidence in your own skills. Blaming management for such fears just takes the incompetence you exhibit to a whole new level of blame-gaming.
I do not fail; I succeed at finding out what does not work.
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.
As a software house we were called in many times as a scapegoat, a game we all knew. A project would not be working and have no hope of delivering, so we would be called in. We would then give an estimate for remaining time and be severely berated for it not matching the timescale, but they'd agree to pay for it to be done. We would take full responsibility and the managers would not seem to see anything strange about us having been working on a project for a week (estimating) and in that time got behind by three months. That way nobody was sacked.
The company programmers themselves did hardly any work. They once had a brilliant young developer who wrote more in three months than their team did in years, before being sacked for delivering code with a bug that caused an outage. The people who survived spent more time covering themselves in case something went wrong tan doing work. For example, I once had a call from a guy who asked "how do you send a block of data to a certain output device". I told him, and years later I saw some code with a comment "IO as specified and recommended by Chris Q of XXX on 03 March 1998", The whole module was covered with comments like this and by the dates it had taken almost a three weeks for this guy to write a program o read a file, and send it in blocks with a maximum length of 256 bytes to an output device with a "continue" flag set for all but the last block. The guy is now in their IT management
I always warned people never to work for that company!
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)
One of the best laughs of the week was when you managed to talk with a straight face about complicated projects being understood well enough. Most peop0le would have lost it after describing such a made up scenario, but you managed to keep going with what looks like perfect seriousness.
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.