Ask Slashdot: Have You Experienced Fear Driven Development? 232
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?
Wow... (Score:5, Insightful)
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.
Re:Wow... (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.
Depends on which country (Score:5, Interesting)
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
Re: (Score:3, Funny)
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...
Re: (Score:2)
I'd say Apple was like that during the Jobs era - Jobs' tantrums are rather famous, and he's one of the assholes that got stuff done.
Maybe his RDF helped couch that fear into a positive by turning into energy to move you forward (Jobs hated behind handed crap, especially if he knew you could do better so your fear of handing him crap made you a better coder by raising your expectations).
Maybe.
All we know now is since Tim Cook knows he can't be an asshole and get stuff done, FDD has relaxed somewhat.
Re:Wow... (Score:4, Insightful)
And you still forget Management by Confusion.
Re: (Score:3)
And Faith Based QA.
Re: (Score:3)
that actually works.
Re:Wow... (Score:4, Insightful)
...and also, FDM - Fear Driven Management.
Eg. "Thou shalt not rework that heap of shit to unblock countless other ideas and projects because it's way too scary".
Re:Wow... (Score:4, Interesting)
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.
Re: (Score:2)
Sure it is. What's happening to programming is what happens to anything when there's more supply than demand: a race to the bottom. Personal computers used to be rare, so programmers could rely on their skills being so as well; now they're ubiquitous, and the industry is entering the same phase others did during the Industrial Revolution. The only known solution is to unionize and bargain collectiv
Re: (Score:2)
I would say that there are fewer people who know how to fix a car/be a mechanic now than who did in the 60s. At least in terms of percentage of the population, if not in total numbers as well. There used to be a lot more people who would change their own oil or do their own brake jobs as opposed to the number of people who would atte
Wow... (Score:2)
THIS. Life's too short to put up with loser companies.
That being said, one needs a financial cushion of 6 months-ish. The easiest way to do that is to skim off 10% from every paycheck [google.com], no matter what.
Remember, you canâ"and should!â"evaluate the company you work for, daily. If they "fail the interview" (i.e., it is more hassle to work there than to find another job) then it is ti
Re:Wow... (Score:5, Interesting)
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.
Re: (Score:3, Interesting)
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 ma
You're funny (Score:4, Funny)
Re: (Score:2)
Management consultant Bob Lewis pointed out that Obamacare would not have been fixed by an agile development path (one of the myriad suggestions). In fact, it was a prime candidate for straight up waterfall methodology. The requirements were right there in The Affordable Care Act passed by Congress.
Re: (Score:2)
If you treat your employees like unthinking peons, they will respond by behaving like that - and that means turning a blind eye towards the innumerable small irregularities and problems a workforce that doesn't actively hate you could easily correct before they have a noticeable effect on production. That is the difference between workplaces where
Re: (Score:2)
A good Waterfall approach gets 4x more done than any version of Agile
Citation needed
Re: Wow... (Score:2, Funny)
Here's a conversation I had two years ago, before quitting my job:
Boss: we're doing agile from now on. We'll be using Scrum.
Me: That's great! So we're doing one month sprints with provisional specs, and fine tuning the design as we go? Who are we working with on the user side?
Him: No, you don't understand. They're not going to be involved at that point. They're signing off on a hard spec, then we'll take over and do Scrum with it. You'll understand when you go for the training.
Me: Wait. There's a
Fear of changing code.... (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.
Re:Fear of changing code.... (Score:5, Interesting)
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.
Re:Fear of changing code.... (Score:4, Insightful)
Except that "new development" and "maintenance" are just labels. As long as there are no new user visible features (apart from improved speed and smaller memory footprint) all development is "maintenance". I understand the rationale between the maintenance / new development budgeting and can totally work within it's framework. But sometimes you just need to clean up code before you can add this new feature (100% "new development") and sometimes you need to replace a legacy database system with a modern one to keep the application running smoothly (100% maintenance). You try to answer the question "why am I doing this?".
The "you can't do that because we don't have the budget for maintenance" is just a lame excuse for two situations, either you just don't have the budget to do it or your manager is scared that you will break something. In all cases it is just a failure to communicate properly, which is especially lame when prefixed with "I would like to let you do this, but..."
Re: (Score:3)
Re:Fear of changing code.... (Score:5, 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.
Re:Fear of changing code.... (Score:4, Funny)
Re:Fear of changing code.... (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".
Re: (Score:3)
Budget (Score:2)
Re: (Score:2)
[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.
What ends up happening in that case is that a bug is found in the "original" (or any subset thereof) code and it's fixed. 11 copies with the bug, authored by three other developers, remain.
Re: (Score:2)
3rd world (Score:5, Insightful)
This machiavellian style of management is akin to slave labor.
Re: (Score:3, Insightful)
But as long as the union bosses stand up for their members then yes a little fight fire with fire is acceptable.
Re:3rd world (Score:5, Insightful)
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.
Re:3rd world (Score:4, Insightful)
And you believe that disbanding the unions will make everyone happily employed
In the midst of the Industrial Revolution we were in exactly the same position you are now
And it took unions and other righteous men to break the situation.
There has actually been a movie about this situation http://www.imdb.com/title/tt01... [imdb.com]. See it and learn from it before you call me ignorant and pompuos.
Re: (Score:2)
Says the third world anonimous coward.
Oh the irony.
Experience counts (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
I would love to have at least one of those fearful devs to handle documentation.
Could you elaborate a bit on that? Because it kinda sounds like you're a tyrant. Why would anyone welcome fear, without being a tyrant?
Re: (Score:3)
I would love to have at least one of those fearful devs to handle documentation.
Could you elaborate a bit on that? Because it kinda sounds like you're a tyrant. Why would anyone welcome fear, without being a tyrant?
The problem is that there is the other side of the coin to people who spend their whole life documenting and avoiding writing code, that is developers who just churn out tons of code say "hey, i don't need o write documentation as the code is easy to read". The problem with this approach is twofold:
1) Your are nearly always a poor judge of your own code, in terms of how straightforward it is. Of course, you understand it, you wrote it. It needs to be reviewed and the reviewer should also determine if it nee
Re:Experience counts (Score:4, Interesting)
I once had a manager ask me to perform a task in a timeframe well short of reasonable. I said "no". He said "with a click of my fingers I can get 5 people just like you who will say yes". I said "go ahead". And ... he didn't. I took the time that the job required, and it worked out OK.
Sadly, refusing to bite on an unachievable deadline does on occasion lead to threats on your job. At the time, I had no family to look after, no mortgage, very few encumbrances. I felt confident saying "no" because I didn't fear losing my job. Now, I'm not sure I'd be so blasé. I'd probably do what I could, then ask for more time. I'd focus on achieving something visible in the short timeframe I had, to buy that time. At the very least it would give me time to look for another job.
It's not so often about being afraid to do your job. It's about being afraid of being set up as incompetent when it is not true.
If it's your job to code and you don't code, then you're not filling the role requirements. But sometimes, refusing to code when coding like fury will not achieve the goal is the better choice. Very often it's the goal that needs to move.
Re:Experience counts (Score:5, Interesting)
I have a wife and 2 kids to take care of. I did in fact have to deal with incompetent management. I indicated a number of times to senior management that there were incompetence problems, but was not taken seriously. I've since decided to take the plunge and told senior managment I'd in fact quit my job per october. At that point I hadn't even started to look for a new job yet.
I might be at risk of being without an income for a month or so, but I couldn't care less about that. I will not be yelled at for deadlines being broken because of mismanagement, or for some obscure bug not uncovered by QA. I'd much rather lose a month of income than putting up with that.
Of course, I have been without income for months in succession, so I've "been there done that". I also have a strong bargaining position, as the company basically is nothing without me. If they don't do their utmost to make sure I stay (get rid of the incompetent manager, offer a raise, that sorta thing) they will have to hire me as a freelancer or suffer the concequences. But that said, even if they choose the latter, I will enjoy witnessing the company die a painful death from the sidelines. I would never try to squeeze myself through a hole that doesn't fit out of fear of losing my job, even though I have mouths to feed. I'm of the opinion that employees (especially IT workers, as many of us are rather shy) should show some spine and command respect. Of course, the respect you're seeking must be proportional to your actual skills, merit to the company, etc.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Of course, the respect you're seeking must be proportional to your actual skills, merit to the company, etc.
Hmmm.. this is the only statement I find questionable. Everything else I agree with. I think everyone deserves respect. The lowest level employee doesn't deserve to be yelled at for missing deadlines, or having a bug that's missed. That's basic human nature, and you're not entitled to it simply because you're more valuable, it's something all people need. I understand your position, but if the
Re: (Score:2)
Re: (Score:2)
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.
Very well said. As I read this summary, I was wondering where this type of "fear" doesn't exist, in any workplace. As a business owner, I have the same sort of concerns, but I dare not fear the result of what the client/management/whatever wants. The best thing that one can do in such a situation, where this type of "fear" exists, is to discuss the things with management prior to doing the work. If they listen, then there's nothing to fear. If they don't listen, it's time to get a new job. Of course I
Re: (Score:2)
Unless it's not just you, but every one of your fellow employees. Then the problem is systematic in that workplace, and thus must be in the system itself.
The thing is, managers are humans and sometimes have serious issues or even outright mental problems, such as ego too powerful for them to ha
What does fear driven development lead to? (Score:5, Funny)
Re:What does fear driven development lead to? (Score:5, Funny)
The dark side of the source they are...
Once you go down that development path, forever will it dominate your release destiny.
I've seen a place like that (Score:5, Interesting)
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!
Re: (Score:2)
[...] 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. [...]
Please tell me this is an exaggeration. Show me a single developer who hasn't caused an issue of some sorts, in production, and I'll show you a developer that hasn't fully matured yet.
Re: (Score:2)
[...] 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. [...]
Please tell me this is an exaggeration. Show me a single developer who hasn't caused an issue of some sorts, in production, and I'll show you a developer that hasn't fully matured yet.
Only slight. He had been given warnings for later delivery previously, and rather than actually being sacked he was told that if he chose to stay he would be held over for pay increases or promotions for two years. And that was a time when two years pay increase would have made a big difference
Re: (Score:2)
Do I know you? (Score:2)
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.
Asshole Driven Development (Score:3)
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.
Free market (Score:3, Insightful)
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.
Re:Free market (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.
Re: (Score:2)
I'm sorry, did you say "four hours a day honing your skills"? Are you nuts? What do you do, learn a new programming language every week and make flash cards to memorize library APIs?
It's hard for me to gauge exactly how much time I spend "honing my skills", because a lot of it mentally falls under "playing" and "cool hobby projects", but I'd guesstimate more like 10 hours a month. If you have a family and your "first loyalty" is to them, spend some time with them on weekends instead of shutting yourself
Re: (Score:2)
You misinterpret on at least two counts, but you bring up yet another good point
First the good point. If you just learn random things in general you will never use 90% of it. I agree, that would be a great time waster.
One cannot learn a real language in a week, though. Python or Perl can be learned enough for a small script in a week, yes, but beyond trivial subroutines there are stacks of advanced books in each language. Take the time to read them. Go through the examples line by line. Mastering a la
Re: (Score:2)
I'm firmly in the camp that you can pick up a language in a weekend. I was once given an interview question to implement a hydrocarbon naming application in Ruby. This was a take-home question, btw, I emailed them my answer:
Given a diagram of a hydrocarbon, give its (algorithmically generatable) name. Trivial? Not really. I didn't know Ruby. I didn't know enough organic chemistry to really understand the question. They knew I didn't know either of these things (they asked).
In the span of a week, work
Well (Score:5, Interesting)
Re:Well (Score:4, Insightful)
May I Translate? (Score:3)
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.
Re: (Score:2)
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.
There was a time when 40-hour weeks were more common, and we got paid "supper money" for exceeding it (being salaried, no actual OT).
We also had to work fairly hard to get laid off, instead of it being the natural fate of the entire department when the project ended/was terminated. Our pre-existing knowledge of the business was considered a valuable asset, and we were seen as flexible enough to re-assign to other tasks, and even pay for training, instead of pulling in a whole new team who knew nothing about
Why Do You Accept This? (Score:4, Interesting)
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
Re: (Score:2)
From my experience: fear usually inhibits creativity. Thus a FDD shop is probably not really innovative.
This may seem suitable for run of the mill work, even there I wouldn't advise FDD. All your good programmers are going to wise up and get a new job, in a company like Gazzonyx's.
Re: (Score:2)
Re: (Score:2)
> It's ironic, I was literally just reading that blog post.
Like rain on your wedding day.
Fair enough. At least I didn't use the term "literally" to mean "figuratively". :s/It's ironic/Strangely enough/
Yes, and "just say no". (Score:4, Informative)
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.
Re: (Score:2)
Since managers don't like problems, bad managers try their very hardest to make you not tell them that you are going to miss the deadline. For example, by overriding your estimates. Without realising that overriding someone's estimates doesn't finish the code any faster.
Happens all the time (Score:2)
Worked at a major software house serving ðe biggest telecom operators all over the world. Ðe company started doing top notch Unix software, even creating its own SQL-like DBMS when Oracle was not good enough. Everyone from ðat era got promoted out of technical oversight over what was produced later, and ðe people who produced software later also got promoted out of technical oversight, so we were left with Microsofties who feared ðe Posix code, did not understand it, and were capa
I've had legacy-product-driven development. (Score:3)
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).
So, never be afraid (Score:2)
does this count? (Score:2)
it's not a coding thing (Score:2)
Fdd isn't a coding thing, it's a shitty-manager thing.
And that's in every business everywhere.
I might have said that as coding drops down the labor ladder (ie the margins become tighter, profits less, that such muggy be more common...but at least in my case, some of the tiniest post little companies I worked for had some great managers, and the great wealthy ones had more assholes....So no, I'd guess that it's universal.
Common Sense (Score:2)
Lets make some notes about your experience:
I worked for a large-scale web development project in southeast Asia
And you don't understand that ridiculous hours and fear driven work style is the norm in this region for many people? Yes, in this region, its not likely to go away anytime soon.
As far as Scott Hanselman's comments, he's mixing 3 different things into the same umbrella, the first 2 of which are actual things that SLOW development down, not drive it. Only the 3rd is what you're referring to. And really, picking a random dude who blogs a lot and has worked for MS
FDX not FDD (Score:2)
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.
Fear-Driven Development is How America Works (Score:2)
Re: (Score:2)
Seriously? This is a post? (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 [bfwa.com]. As I have said ad infinitum and ad nauseum, not only do they keep re-inventing the wheel, they keep reinventing the flat tire.
Re: (Score:2)
... they keep reinventing the flat tire.
awesomesauce!
I am absolutely going to say that in the next meeting I go to
Re: (Score:2)
Half way through your post I wanted to scream "It's great we have these books but goddammit, people are STILL making the same mistakes!!!"
FDD exists for only one reason... (Score:3)
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"
Re: (Score:2)
The problem is that *any* IT problem can be solved eventually. And if your colleagues tell their managers that they can do it, where do you stand?
Re: (Score:3)
Where do you stand? at a better job at a different company.
you can hide under your desk and hope your master will praise you, or you can demand being treated like a professional and demand the respect and be treated as an employee and not a slave.
there should be some fear (Score:2)
I trust you can see how that sort of environment sucks as well.
Answer (Score:2)
Have You Experienced Fear Driven Development?
Is there any other kind?
Shops Like That Get A Reputation (Score:2)
Yes, but you usually have a choice (Score:2)
At least in the US there are countless software/IT jobs because every business relies on software for its continuous existence in some way. Yor may have to downsize and live on lower wages for some time, but you will live.
Thoreau already covered this (Score:4, Insightful)
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.
Culture Matters. A Lot. (Score:2)
It's not fear driven development. It's incompetent, obsolete management.
FDD? That explains it! (Score:2)
I once used a word-processor that accidentally opened a pop-up saying:
"Help! I'm being held in an office in Seattle. Please contact the police!"
Yeah, I've seen it (Score:2)
Intentionally used.
It happens when someone in management or preliminary design fucks up in the early conceptual stage. So fear and panic are used to keep everyone's head down instead of looking around, asking who made these shitty design decisions.
Of course it is. (Score:2)
Not sure... Good people can grow up (Score:2)
I have recently after 3 years sabbatical started my first commercial development project. It will be a web based database and system manager. I have spent many hours researching the right tools and designing the right database scheme for the entire system. I have begun designing the goals of each sprint while setting realistic expectations for each developer.
Once the project is started, we will employ SCRUM in a modified form. Test driven deve
Try Fear Driven Testing... (Score:2)
I worked for a video game company where the new manager ran the QA department like a personal dictatorship. You were either with him or against him. He came down hard on me because I documented EVERYTHING as a lead tester. The previous manager nearly got fired because I documented his decisions that caused two of my projects to implode, and got "promoted" to associate producer to the corporate office in NYC. The new manager didn't want me to document any of his actions (most of which would cause heartburn f
Re: (Score:2)
Having some experience with both FDD and TDD, I can attest that test driven culture where automated testing is fully integrated into the dev process pretty much addresses all three of your conditions.
Or combine them. I've seen amazing things happen when the developers are fearful of the testers.
Re: (Score:2)
Do you have videos of the blood on the carpet?
Re: (Score:2)