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?

9 of 232 comments (clear)

  1. Wow... by DoofusOfDeath · · Score: 5, Insightful

    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.

    1. Re:Wow... by MadKeithV · · Score: 5, Insightful

      A small number of dysfunctional shops like that has virtually always existed.

      90% is a small number, right?

      I'm joking, I've never had to work in a truly dysfunctional shop, and yet "fear-driven development" tends to make an appearance whenever stress levels get higher. Pressure makes people take funny decisions that they think are "safe", such as not touching a legacy code base for another 5 years because "it works and we don't want to break it", until it finally collapses under its own weight and technological advancement (in the case I'm thinking of it was the lack of multithreading and 64bit support).

      Often its the fear of other people's reactions if you stick your neck out and get it wrong that will doom you to inaction. It helps to remind yourself and others constantly that you cannot have improvement without change, and the only way to do nothing wrong is to do nothing. Build up trust at detecting and *recovering* from mistakes is at least as important as having a process that avoids mistakes. Mistakes happen. Learn to deal with them instead of expending inordinate amounts of time trying to avoid them.

  2. Fear of changing code.... by justaguy516 · · Score: 5, Insightful

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

    1. Re:Fear of changing code.... by MadKeithV · · Score: 5, Insightful

      I have also seen/heard of circumstances where "doing the minimum to keep the thing working" is allowed but actually improving the code is not because improving the code counts as "new work" and comes from a different budget than maintenance. Seems stupid but that's how some shops operate.

      "The minimum to keep the thing working" nearly always implies improving the code. All developers need to realize this and stop this silly false dichotomy between "maintenance" and "refactoring".

    2. Re:Fear of changing code.... by rioki · · Score: 4, Insightful

      No it compares to: You told(1) me to inflate the front left tire, but the tire was worn and had a hole, so I needed to change the two front tires. You should also consider changing the back tires and the brake pads look worn, but it's your car.

      (1) "I don't care how, make it work!"

      I am a lead developer and bill against two accounts when developing (a third account when I tell people what they should do). I resolve the issue by simply looking at why I started working on something. Did I start working because bug or performance issue forced me to improve the bit (maintenance) or did I start adapting a piece of code because of a feature request (new development). By keeping the "boy scout mentality" (leave the code in better shape than you found it) my peers and I are able to keep a body of software running that was originally written in 1993. Just because you are slightly bending accounting nitpicking does not mean you go gung ho hacking though the code. By the way we are going to release V8.1 next month.

  3. 3rd world by goarilla · · Score: 5, Insightful

    The only thing I will say is that emerging economies need Unions !
    This machiavellian style of management is akin to slave labor.

    1. Re:3rd world by goarilla · · Score: 4, Insightful

      I'm a European, we've had fairly decent unions over here.
      That your unions were run by maffia front-man for decades reflects on them personally
      not on unions as a concept. I accept that you're skeptic.
      But somebody (unions, governement) does need to reach for and uphold a decent quality of living and good working conditions are crucial to that.

  4. Seriously? This is a post? by bfwebster · · Score: 5, Insightful

    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)
  5. Re:Free market by Princeofcups · · Score: 5, Insightful

    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.