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?
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 maintanence.
Seems stupid but that's how some shops operate.
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.
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.
I've worked in both environments. Where I currently work we have a daily Scrum (in name only) and we only cover three questions:
It's a liberating thing. I can literally call someone else out for blocking me, or they can call me out for blocking them. Our manager can say, "I understand you were working on X, Y, or Z yesterday, but Alice, Bob or Carl needs you to work on this today so they can get their stuff done." It's simple, it's effective and it makes the team more coherent and cohesive with nothing more than a 15 minute "stand-up" (we all work remotely on any given day and we do the Scrum via Google Hangouts) at 10 AM. It sets the tone for the day. And it only costs our attention for 15 minutes and willingness to be reasonable with other professionals on our team.
We don't have:
To be honest, FDD seems like a culture problem more than anything else. You're a professional. Act like it and expect those around, and above, you to act like it. If your culture is so messed up that you suffer from these problems, it's most likely just the tip of the iceberg of the organizational challenges that your company faces.
"Of course, that's just my opinion; I could be wrong" -- Dennis Miller
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
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 !
Agile itself has a process for this (marketing can request all of the features they want, stack rank them, and pull into the sprint what can be done in the sprint --- keep working on the project until the budget is gone or everyone agrees it's complete). However, most people doing "Agile" aren't really doing Agile......they're doing more of an iterative-waterfall with the overhead of certain Agile processes. I've worked at places that do both and where they followed a truer Agile process, they got more done and the staff was less stressed.
You are damn lucky. There are a lot of shops, if not the majority of them, are FDD driven. However, with offshore companies like Tata whom can be argued to be the best coders in the world by the managers I worked for in dev houses, it is no wonder why there is stiff competition in anything development related.
In the real world, with managers who are verbally abusive, it would be nice to have the luxury to leave, but there is this thing called rent, and food bills that have to be paid, so running for months without an income (if the employer were any good, they wouldn't be hiring in the first place since they would have positions full by word of mouth and private networks) isn't an option for most. Plus, the abusive managers can always deny that the person worked there (to the point of claiming the person is a mentally ill stalker), and completely hose the ex-employee at a whim. In fact, just being unemployed makes it extremely difficult to find work just because employers who have their H-1B quota will not hire anyone who isn't employed.
I got introduced to the FDD method at one place. The LAN was down. A co-worker found that it was a cable issue and reported it. Security walked him out at once with a taser to the back of his neck and held him until the police came, claiming that he violated the CFAA. When the police arrived, he was told that he either signed a form that he would release the company from all legal damages, that he was fully paid, he acknologed being fired on the spot for gross misconduct and that he will not be filing for unemployment, and he admitted responsibility for the network outage for civil litigation later, or felony charges would be filed. Well, he signed (later showed me the contract), even though technically he was owed two weeks back pay, since fighting felony charges would take more money than losing that job.
Another place was a call center for customers to report issues. They required people to be -on a call- when their shift started. Green light on ACD not on? Strike. Three strikes? Immediate termination. If phone stats went below a certain level, the first time, it was a yelling at, second time, a pay dock, third, a walk. Since it was contract work, if one got sick for more than a day, they were promptly replaced by another, as this company has a waiting list for those positions.
The FDD method sucks, but it does work. It is a choice to working like that, or "enjoying" life with the hobos under a bridge. The days of being able to choose a decent job here in the US are over, as those jobs are in China now.
A good Waterfall approach gets 4x more done than any version of Agile - on a complex project that can be understood well enough to design before most coding. Agile is good for reporting and projects where a client just wants to throw money to "get somewhere" but really don't know what they want.
Agile is not a development method. It's a client control method. The client (business) sees something tangible and imagines that they can follow along and have some control. It's mostly an illusion, as is most management.
The actual development methods to make Agile successful (at least from a technical perspective) are Regression Testing and Code Refactoring. Most Agile projects that fail are because of one or both of those areas failed.
As for FDD... standard on the east coast USA and many other parts of the world. It works for unthinking peons but utterly fails for jobs that require imagination.