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!
So you worked on that project too then?
Seriously, are some of the fears you mentioned not present in almost every project? My experience is that the more a project goes wrong the more the 'forces' mentioned above tend to make things worse. In that case only strong leadership that holds on to a clear vision and keeps the team away from 'the blame game' is the only way out.
If not: run. Don't walk away. Run.
As a contractor you don't have a career that loosing your current contract isn't really a big deal. So having FDD you just don't extend your contract in 3 Months.
I've had plenty of ADD (Asshole Driven Development) I tend not to renew them either.
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.
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.
Ask Slashdot: "Aren't most programming projects over-budget, behind-schedule, and eventual failures? Just like countless studies, textbooks, etc. have documented for as long as there has been IT?"
This isn't some new shocking trend. There was not, in the misty past, some sort of utopia where programmers regularly worked 40-hour weeks, never got laid off, were well-managed, and code shipped on-time, bug-free, and projects never got canceled because of screwups. I'm pretty sure every Software Engineering course ever touches on at least some of this.
Just about any complex project in any industry has a ludicrously high failure rate. Starting a new business, launching a new consumer product, designing and building massive complex machines, running governments, etc.
There's always a lot of ways for things to go wrong, and far fewer ways for everything to go right.
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.
I suspect we've all encountered managers that don't grasp the difference between "managing" and "intimidation". But after your first job out of college, you will discover that you have better things to do with your life than burn the candle at both ends for a crappy job.
More importantly, the "death-march" style of project management doesn't produce good results. What you describe can't become the norm, simply because any company that uses it will find itself internally paralyzed, completely unable to adapt to a changing market. When individual projects stretch on for longer than the company's strategic plan, the threat of firings doesn't really mean much because none of you will still work there in five years.
Find a new job today and save your sanity.
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 !
I hate this. It's pretty much impossible to test for complete identity with the old product, unless you build an exact copy of the old product (which you no longer can, thanks to RoHS and such).
I’d guess that FDX (Fear Driven X) exists in nearly every industry. Google “motivated by fear” or “driven by fear”, and you won't just find a bunch of software development articles. This is a human problem, not an engineering problem.
Figure out how to stop this type of behavior at a larger scale, and the answer will probably apply to the smaller one.
I once worked for a large U.S. based company. They used to make computers but have sold off most of the PC and Server business to Asia. I worked in the Software Division. Fear of loosing your job was routine. This was also true in the hardware end of the company. Fear of breaking the build and the punishments for making anything new or novel were a daily constraint. The company now makes much less software and the only viable revenue stream is a Services business that depends on how hard the older software is to use. They used to pretend to use Agile at my location. We had fake scrums and so on to document the waterfall development that was the real process. I am a happy ex-employee as are thousands of others. The MBA ROI and cost cutting culture along with a Don't Report Bad News Up policy will, I think, kill this and other Western corporations. The only way to create is to fail over and over.
Gee...
I'm Banging My head, trying to think of which company that is...
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)
Sheeple programmers that dont have the balls to tell their managers. "go fuck yourself"
Stop letting people roll over you and treat you as a slave. You are the expert, and if you are actually good at what you do you can stand up and say, "no! that is unreasonable"
Do not look at laser with remaining good eye.
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.
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.