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.
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.
This topic is basically just an open invite to bitch but I'll bite. I worked for an asian defence contractor and they basically used "fear driven development". They exploited our ethics and morality because they knew we wouldn't compromise on quality assurance and reliability because it would end up killing or maiming people, so they pushed us as hard as they wanted when it came to hours, requirements and deadlines.
Typical urgency-based development. Unfortunately it is a very common manipulation mechanism at the workplace. Here's a thorough article just about it http://outofscopeexception.wor...
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.
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.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
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.
I've worked in places like that, I left - in part because they weren't interested in improving themselves, I was becoming a poor developer as a result of the methods and constraints they forced upon us, and I generally hated it
I've since worked in a few places (contracting now, not permanent - you get to learn a ton more this way I find), and while FDD certianly isn't a large majority, it's not a minority either. I'd say at least 35-40% of the places I've worked have had some form of FDD affecting their projects.
All I can say is get the hell out, now - leaving that position I was in (for 5 years!) was the best thing I ever did, there are far better opportunities out there almost always (even when you think you've got it great, it's amazingly rewarding learning completely different fields, experiencing different work environments, and generally getting a feel for what's out there) - you'll come to realise what matters in your day job, and from there if you have the skills you'll likely end up hitting a company that fits you perfectly and they'll do their best to keep you.
It gets better.
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.
Someone has to be in the bottom 10%....
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.
And what if the management is actually the incompetent part?
Do you have videos of the blood on the carpet?
Sent from my ASR33 using ASCII
I'm in the midst of one right now. My depression sure doesn't help the matter either.
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.
...is mainly FDD!
Are abusive relations between managers and developers here to stay? Are deluded managers here to stay? ... guess what, those things have repercussions, don't they?
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.
Developers did not write Agile/Scrum. It was made by some MBA's who wanted a way to try and evaluate a project. Not an unworthy goal. However they didn't realize that the people who would be using this system would frequently be idiots. People who don't understand how coding works, will while away your time on stupid story driven development. They love moving their tasks from one column to another, and watching the burn down chart. This ends up happening, because people who can't see coding, say it can't be managed, or made visible to people on the outside. So you are going to end up with something or another, Scrum is not so horrid, it is actually more or less what you are doing already. WIth a little more overhead. Agile is a fucking sick joke. I met the guy who made that, my company paid him some $5k to come talk to our developers for 2 hours. He went on and on about his family for 2 hours. Afterwards, I bought him a few drinks at the place across the way. The guy was nuts, but he did tell me that he wished he'd never written the Agile system. Though I am sure it continues to make money for him. Selling is his damn book.
When it comes to Agile, you'll find that it slows down the very good developers, and pretty much brings to a halt any work by the dumbest ones. The dumb ones however have the advantage. They will generate the numbers instead of doing the work. And that 2 minute task will end up taking 2 days. But you see, it's written down! The very good developers will be at a loss to explain how they only got one task done, as their task was truly a 50 hour task.
In the end Agile, rewards bad developers, and either breaks down, or pisses off the very good developers (to the point where they leave.) Also Agile can be used to target "undesirables" for termination. Those developers are given many tasks truly long development times, but their development time is like 10%. When that developer cannot explain why it will take longer, people just say "we'll just go with the original estimate then." Then those people don't get the tons of work done, and the whole project failure is pinned on them. Then they are fired. I've seen it happen a number of times.
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.
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.
The wrong kind of TDD leads to FDD of the type where you're afraid to break the build.
The problem with TDD that leads to this is that TDD is almost totally reactive; that is, you find a bug, you write a test for the bug so you can tell when it's gone; you get rid of the bug, and now you have this test which is going to be run on each build, as if you are not already hyperaware, having both experienced and fixed the bug, of the conditions leading up to the bug. The annoying part, of course, is when you start taking longer and longer amounts of time to get through the build to an acceptance of the build, for each test you add. Then to make things even worse, add to that the occasional false failure because the test is flakey, but it's someone's baby and it "usually works" and the failure is "timing related", and now you're testing the test, and rejecting a perfectly good build because you're unwilling to either rip out the test completely, or make it non-fatal and assign the bug on it back to the person who wrote the original test.
TDD with test cases written up front, and not added to without an associated specification change: Good.
TDD with test cases written to cover historical bugs identified through ad hoc testing: Project Cancer.
The second worst thing you can possibly do is write tests for no good reason because you're able to write tests, but unable to contribute to the core code, and you still want to contribute somehow. The worst thing is being the code reviewer and letting that type of mess into your source tree because you want the person submitting the tests to not feel bad about them not getting accepted.
But I've read about it enough. For example for the development of Starcraft they followed similar hours.
Going through it right now at work...a major telecom company.
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 !
Sounds like a good time to start looking for new work, eh?
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 capable only of implementing overdue business requirements, not of any technical improvement or even technology updates.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
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).
It doesn't matter how much lashing you take from managers, co-workers or senior management. If something is wrong you need to point it out and stand up until it's fixed ( usually meaning you fix it! ). I was a on a project where my boss insisted on outsourcing all the programming to India to save money, it took over a week of arguing with him to make him realize that saving money doesn't make up for quality. I've been on other projects where marketing gets to set the requirements and managers pretty much adhere to "If marketing wants it, they will have it". In all cases the role you have to play is the same, stand up to people and tell them they need to fix the steaming piles of shit now before it snow balls. If you get fired for being right and standing up then good, it proves you have more integrity then the company did, if you get verbally beat down then it usually means you're right and should keep pushing back until something is done.
i've experienced fear driven life.. i think that's a sufficient catchall
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.
-Styopa
..the time of my life. No I never felt like this before..
Welcome to the world of consulting!
I thought Dave Cutler was still at Microsoft..
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 for a few years probably isn't the best place to quote. He's got nothing really that impressive to make him an expert on properly managing development practices that most people don't have as well.
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?
Yes, your single experience is an indicator of how the whole world is going to operate for the rest of eternity.
Or not. Your experience is indicative of local culture, be happy they let you off one day a week and gave you pizza, most won't get that.
In the rest of the world, no FDD is a rare thing that usually is one of the last things a company does before it collapses into a heap of rubbish and ceases to exist because the only people working at it are unqualified people who can't get a job ANYWHERE else, so they HAVE to stay there.
FDD is the result of managers not having any clue about how to manage people, nothing else. The solution is to go somewhere else. In the case of southeast Asia, you probably will have to physically move somewhere else to get away from it, but thats better than jumping off the roof in a year or two.
The fact that you're posting on slashdot means you don't live in a country that will prevent you from changing your situation, only that you have not bothered to change your situation and seem to think your one experience is how they all are.
That or you're just Scott Hanselman trying to drive traffic to your blog in a slashvertisement ... which seems more likely, because otherwise your post is kind of dumb ... just like Hanselman's blog entry on the subject.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
The last place I worked for has a CEO that made the office thrive on conflict. Everyone was afraid of not writing the very best code possible. If you turned in something that wasn't 100% perfectly written and would get anything less than a 4.0 from CI you'd take heat for it. It made it impossible to work on any fast paced innovation. On top of that, the CEO was one of these people who read every single leadership and team building books he could find. He's change up our scrum focus every month, have us rearrange the office layout every 2 weeks, etc. He'd give you new responsibilities on the next cycle to make you feel more in charge and then hold it over your head like the sword of Damocles. It never left me in a comfortable place to work. My true fear was that this was how offices were evolving.
I worked (shortly) for a company, that quite frankly, had a great product. However, all the very hard technical parts had been written and those who wrote that had moved on. What was left was a team of developers working on the ui and fixing bugs.
It was an Indian (like, from India) owned company that hired a lot of Indians. The problem was that they would get these workers in, who were leashed to the company, and then, as the OP stated, used FDD to get work done.
So, say it's monday, and we need to have the product ready by Friday. We can honestly say it REALLY needs to be complete by next Monday, since no one is going to demo it on Friday, and since we could work the weekend if need be.
They would have a meeting and say we have 50 bugs that need to get fixed by Friday, that's 10 a day, we 10 developers, so if each of you closes out a bug a day, you wont have to work this weekend. What they don't tell us is that they have 50 bugs at a certain priority, and 400 at lesser priority's. If we finish 50 of the bugs, and none reopen, they just take more bugs (from the 400) bucket, and make us work the weekend anyway.
They did this seven wekends in a row. I flat out quit. I went home at lunch and never came back, I was so pissed and I just wasn't gonna take it anymore.
I mean, I saw some of my peers literally cry because they had their weekend taken away from them AGAIN. And like I said before, some of my peers cant quit or they would get exported back to their home country, and their families would be shamed.
If you work for a company that uses what op calls FDD, you have two choices; stand up, make the problem known, works towards fixing it
Or, you quit, that's a broken business and you don't want to support it, its not Terry Shiavo, its a business, its okay to let them die.
We do this too, however Eric always talks about non v15 stuff, and Seth talks about (i dont even know, when seth talks i usually start reading slashdot)
How do you keep people staying on track?
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.
Till the point where the 'automated' is considered more important than the 'testing' part and people stop tinkering with the software anymore ; oh, the automated tester will test __everything__.
I am an American worker. Fear-driven development is the status quo. Fear-driven work is the status quo. I fear poverty. I fear destitution. I fear being unable to have any time to actually live because the struggle to maintain my continued existence takes all of my time and energy. Getting a new job doesn't help, because I'm still a wage slave. Forming a startup won't save me, because equity doesn't pay the rent.
I write sci-fi for metalheads
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.
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.
MBA management, they know nothing but tell you to do everything for them. FDD for me is management run by people who knows nothing about what you are doing. Just like users, saying i just ask for this simple change. They don't realize it may take hours, days, or even could break the whole thing. They don't realize you'll have to do all tests again for this 'simple' change. But those are users, you can appologize, is not be the same when managers play the same game, but it happens, just too often.
Run by FDD, think of getting another job, find an umbrella, or another role in the company, or better run your own company, if you have enough skills.
But be sure, they may have trained you to be real efficient, in time and all, now is time to run your own business, with long time innovative ideas you built in mind, in your own company.
The best you'll get from them, is discipline, and fill your stomach. The best you'll get to have another job, in a better company or your own company, is the sky the limit, and your first employer 'a bad souvenir'. You must start somewhere. But as experience improves, you become unvaluable, if not recognized, just go away.
The opposite of "fear driven development" is a total lack of accountability, excused under the banner of being "agile". Miss a deadline? Who cares! Dragging your feat on a work item that's blocking someone else? Who cares! Break the build because you didn't even run your code a single time before checking it in? Who cares!
I trust you can see how that sort of environment sucks as well.
Have You Experienced Fear Driven Development?
Is there any other kind?
Free, as in your money being freed from the confines of your account.
When someone uses low emotions such as fear and force to manage with it simply says they have very poor, or no control at all, and no doubt lots of incsecurities. They cannot control others, and probably not themselves. Not being of management quality they use what is real to them, in other words how they view life which for them is a life full of fears. Others, like bullies, try to hide their insecurities by pushing attention onto others through the use of force. Of course all it does is a reverse effect, it really only puts more attention onto them.
Where you able to sit down with these type of people on a one on one, you will usually find just another scared person trying to make it, however poorly they go about it. I've been face to face with cop killers, murderers and gang members. Underneith it all they are all just like us, just not very successful in winning in our society. Their emotions got the better of them, their own values and solutions not really being in their own best interest, all put them on what is more or less a one way street. (Not to say that I in any way condone their criminal actions, but having lived life and seen the upper side and the under belly, and all the nooks and crannies of life I've developed an understanding of life and people.)
I once worked for a company who during 9/11, when no air cargo was flying, came and threatened to fire me if I did not come in and work on the Saturday following the reopening of the airways. I immediately said "OK, good bye then!"
Her response was utter amazement mixed in with dispair. I told her that she just walked in and threatened me, did not even bother to ask if I would mind coming in, which I incidentally had no problems with. I told her that I don't work under threats, but if you take the time to consult me you will find a person very willing to help. She took that in for a bit and then asked me if I would mind coming in, and I said "Sure, happy to!".
I long ago settled with myself that if I cannot be myself in any situation and this kind of things would occur, it was not a place for me, and that I will be better off somewhere else. (I like to work because I pretty much choose what I want to do. My daily actions are of my design, however good or bad. I'm at the helm of my life doing what I want to do.) Being true to myself has brought about an inner peace which I prefer over trying to be someone others may want me to be. Which I probably cannot be successful as anyway.
Obviously my recommendation is to move on. Find a person who is competent, someone who has warmth and compassion in their eyes. Though having money can, it does not have to equal competence, and you want to be part of a compatent group. They will value you and realize that people are important. Remember that the attitude of the owner will shine through the rest of the company.
Funnily enough, contractors are usually get a better work/life balance at the grind-houses I've seen lately. The companies will abuse their salaried work base for as many free hours as they can get, but contractors put in their 40 a week and are done. You can tell when they're actually desperate to get something out the door because that's when they ask the contractors to work paid overtime.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I've had some decent software development jobs, and some really lousy ones. I looked at each one as a learning experience, and the lousy ones I just stuck with until I found something better. The thing is too, you can always speak up about things to your manager. If they're decent they might do something if they're not decent all well you didn't lose anything for trying. Be prepared that you might not have a job; however, most companies don't like to lose people who've been on a project over a year since it costs them way more to lose someone experienced than to train someone new. The only exceptions are people who just can't get with the program. Hang in there, and if you're working crazy hours ask to work from home occasionally with the excuse that you will be more productive, and then take some time out to interview on your work from home days. Once you land a new job, leave the old one because 18 hour days are not sustainable by 99.9% of people in the world. Good luck in your search, there's plenty of IT gigs out there so you should be fine.
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.
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.
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.
As a parent I experience it every day.
Bark less. Wag more.
get the hell out of there...
Many jobs and even volunteer work or life in general can be fear-driven if those in power want it to be or if they just don't see a better way of doing things.
It's not fear driven development. It's incompetent, obsolete management.
-- $G
Try every day of My current job. I only stay because I am at that awkward level of expertise where Nobody wants to pay enough for Me to support My family while not being qualified enough to get a comparable job. My Employers insist on doing things the old fashioned way (e.g., My Boss insists on using Windows 98SE machines and insists Windows XP, Windows 7, Windows 8, Mac OS, etc., are just fads), My paychecks are often late, randomly reduced whenever My Boss feels like it, if paid at all. One of My Bosses talks constantly about how People of My ethnic background should be rounded up and shot, how all science is a fraud except when it "validates" white supremacy, and how Anyone expressing any form of disagreement will be immediately fired with extreme prejudice. How long have I been here? Too long. So much so My Physician says the stress has shortened My Life expectancy to about another 15 years and I'm not even 40. So, yes, I have and do.
"Fear of changing code" is countered by a revision control system. If someone indeed breaks the build - revert!
I can tell you form experience that working for a top game company (multiple Game of the Year titles) is pure FDD: huge tangled codebases, "you break it, you've bought it" looming doom, and a revolving-door approach to employment. It's why I tell people that, yes, making games is fun but working for a game big game company is anything but. I'm know other game developers out there have had similar experiences--I've heard some of their horror stories too.
One way to slow that bloat down is to put a limit on the number of test cases.
I think it is about having a small testing budget. You have budget to test the new feature but not the budget to test the whole application. Testing the feature involves the developer and client doing a day or two of work. Testing the applications involves a team of people running several days worth of formal tests. It is purely rational to push such testing off untill you have a larger release. One problem with Agile is you never get such a release. As everything is done in smaller chuncks.
Yea I would never, ever work for 18 hours for Anyone.
Nice to have the name for this now - it was my last job experience however and does seem like the trend I've seen. Quality seems taboo while schedule and features are the real tyrants . And Agile seems like the path to hell paved with good intention. Coders increasingly seem like commodities instead of human beings with feelings and concerns who may want and deserve to have lives beyond the workplace. I don't see things getting any better before getting worse; far worse - for the 99% of us.
I know a company that would take their initial estimate on a small project and then multiply it by four to get the actual cost. It seems pretty standard actually. By comparison I take my initial estimate as a programmer and multiply it by two and after I'm done with the client hand-holding and revisions I'm right on mark. To me that just means management just needs to get out of the way and let their devs do the work.
The logical outcome of Fear Driven Development is Fear Drive Documentation. I once had the great misfortune to work for a "vanity" software firm created by an industry legend as a nice place for his kid to work. The "standard" work week was a mandatory minimum of 50 hours, getting paid for 40, of course. I never worked less than 60 and the usual was around 70. Working in docs (solo under ten developers), my job was to fix the paper to match the latest suite of changes. If the developers worked in fear, then I worked in stark, raving terror. To match the shipping schedule, I issued 12,000 pages of docs in a year. Adding to my joy, one project manager had the temerity to complain about 3 typos in a 1,000 page document set. The conversation that given the choice between a few typos and missing documents did not go over well. And yes, the company did fade away, but not before I was replaced by a manager and three worker bees that promised less than half of what I had done and missed even that low bar.
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!"
If Pandora's box is destined to be opened, *I* want to be the one to open it.
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.
Have gnu, will travel.
Sounds like Jengaphobia to me.
My last job I worked as a System Admin for a Pharmaceutical Manufacturer.
I had 7 NT SERVERS (in 2012) because of FEAR of the paper work and the validation process because they were touching the manufacturing process of OTC Drugs.
I wasn't allowed to install CUPS on our AIX 4.3 Server out of FEAR of the paper work and the validation because they were touching the manufacturing process of OTC Drugs.
I had a brand new 2008 R2 Server sit on a bench out of FEAR of the paper work and the validation process for 2 years because they were touching the manufacturing process of OTC Drugs.
I had a new Firewall sit in a box for 1 year out of FEAR of the paper work and the validation process because they were touching the manufacturing process of OTC Drugs.
I haven't gotten a raid for 4 years out of FEAR of the paper work and the validation process.
I'm so happy I left!
I got to work on a project for a few months, with a government organization. The previous manager, who had since left his position, was highly abusive, and did not understand the code base. I heard (second hand accounts) about how the organization would hire truck loads of developers, throw them into the project, with no explanation or training, or even time to learn the code base, and expect them to perform from day one. If they did not perform by being able to develop a single app page within their limited time, they would be excoriated by the manager, then summarily released and fired. It was a "code or die" situation. The developers would be in a constant panic, and I heard that several of them broke out in tears from the stress. By the time I got there, there were only five people on the team, but the "fear" in the air was so palpable you could walk into it and break your nose if you weren't watching where you were going. The remaining team was evidently traumatized, and the new manager, the former lead developer, would panic whenever I would attempt to discuss the large database code that needed to be addressed as part of my tasks. It was amazing what a mismanaged structure and fear of losing your job or getting sued can do to the psyche of a human being. I didn't stay there more than four months. That sort of fear, with its entrenched demands for "survival", was extremely damaging. I'd recommend that if you ever run into one, just get out of there. Your sanity and mental health will thank you for it later.
Fear has been effectively used to manipulate and manage humans since before recorded history. It has marshalled armies, driven religious conversions, mass exodus, and chilling human sacrifice. How would you imagine so effective a tool might be abandoned by those who would control their fellow man, for their own gain? Every day we are pummelled with fear-driven political ads and "news" broadcasts. Even our parents use fear to manage their upstart offspring. Fear as a tool of control is, I fear, here to stay.
Excuse me, what are the Requirements?
Oh, you don't have any.
Where are the Design docs?
Oh, Joe knew, but he left.
The test cases?
What is reverse engineering? Where do I buy reverse engineers?
I left development when I saw what you call FDD be used in SCRUM.
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 development is a minimum requirement. Three people will write tests and two people will implement code.
I will use mediocre developers which are inexpensive and instead of writing code myself will constantly adjust the project to adapt to the resources on the project. I will use no "Star Developers". I'll trim out dead weight too. Everyone will pull their own weight. If I end up with a Star Developer", I'll trim him/her as well. I believe "Steady wins the race". I always want people who are happy just to code and get paid. I'm not interested in artists or creative people. Implement the code.
I didn't get creative with the design. I used methodologies that date back to 1969 and work. No fancy thinking... It was boring as hell. The point is simply to create a project with top quality and high maintain ability and a low cost in a reasonable period of time.
This is 2014... We have done it already. We don't need to write a new language, design a new method, invent a new management system... We need to build programs or tools which work. Creative people can make games. Weaker people can go back to school or change printer ink. Average is best.
Tests need to be fast and repeatable (among other characteristics). Tests must be of high quality as your production code. If you would fix "timing related" issues in your production code, there is no reason your tests suffer from the "timing related" issues either.
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 for HR) and thought I was out to get him like the last manager. The truth of the matter is that I didn't care about these paranoid basketcases.
Wasn't long before I got a written warning for "insubordination" by not following his directions that would have a negative impact on my project. He followed it up with his infamous "my way or the highway" speech. So I took the highway and left the company after six years in 2004. I was the third out of a dozen senior testers who left the department that year. A decade later, the QA department is no more as the company stopped selling PC and console games, started making FaceBook games with limited appeal, and rehashing past products for online distributions. I became an IT support technician who no longer had to deal with fear driven management.
...is the economic powerhouse it is today...
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, 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 time to Let Them Go.
Yeah, right.
Yes, I experienced this at SanDisk all India caste company and Futurewei. I will never buy sandisk because it it. Terrible people there.
Tests need to be fast and repeatable (among other characteristics). Tests must be of high quality as your production code. If you would fix "timing related" issues in your production code, there is no reason your tests suffer from the "timing related" issues either.
There's no reason they *should*, but they do unless you correct the test. The problem is in the test code, or in the wrapper that runs the test code. But consider an automated login test on an isolated network with a credentials server that races to come up with the browser that's attempting the login in the test case. If the login happens to start before the login server gets up and stable, then your login fails, and so does your test case, even though it's not a problem with the browser you are nominally testing.
This is/was a pretty common failure case with the ChomeOS build waterfall because Chrome was considered an "upstream" product, and therefore changes in Chrome, when they occurred, could throw off the timing. There wasn't a specific, separate effort to ensure that the test environment was free from timing issues. And since you can't let any test run forever, if you intend to get a result that you can act upon it in an automated way, you get transient failures.
Transient test failures can (sort of) be addressed by repeating failed tests; by the time you attempt to reproduce, the cache is likely warmed up anyway, and the transient failure goes away. Problem solved. Sort of. But what if everyone starts taking that tack? Then you end up with 5 or 6 transient failures, and any one of them is enough to shoot you in the foot on any given retry.
Now add that these are reactive tests: they're intended to avoid the recurrence of a bug which has occurred previously, but is probabilistically unlikely to occur again; when do you retire one of these tests? Do you retire one of these tests?
Consider that you remove a feature, a login methodology, a special URL, or some other facility that used to be there; what do you do with the tests which used to test that code? If you remove them, then your data values are no longer directly comparable with historical data; if you don't remove them, then your test fails. What about the opposite case: what are the historical values, necessarily synthetic, for a new feature? What about for a new feature where the test is not quite correct, or where the test is correct, but the feature is not yet fully stable, or not yet implemented, but instead merely stubbed out?
You see, I think, the problem.
And while in theory your build sheriff or other person, who's under fire to reopen the tree, rather than actually root-causing the problem, doesn't have time to actually determine a root cause. At that point, you're back to fear driven development, because for every half hour you keep the tree closed, you have 120 engineers unable to commit new code that's nor related to fixing the build failure. Conservatively estimate their salary at $120K/year, then their TCO for computers and everything else is probably $240K/year, and for every half hour you don't open the tree back up, that's ~$14K of lost productivity, and then once you open it up, there's another half hour for the next build to be ready, so even if you react immediately, you're costing the company at least $25K one of those bugs pops on you and you don't just say "screw it" and open the tree back up. Have that happen 3X a day on average, and that's $75K lost money per day, so let's call it $19.5M a year in lost productivity.
This very quickly leads to a "We Fear Change" mentality for anyone making commits. At the very least, it leads to a "We Fear Large Change" mentality which won't stop forward progress, but will insure that all forward progress is incremental and evolutionary. The problem then becomes that you never make anything revolutionary because sometimes there's no drunkard's walk from where you are to the new, innovative place you want to get to (eventually). So you don't g
eom
I spent years working for organizations whose upper management thought forced ranking (where each employee is placed on on scale relative to others) was a good idea, and, later, instituted periodic layoffs (first annually, then semi-annually, then quarterly). When you work in that kind of environment, you've implemented FDD whether that was your intent or not. It's just another example of what Robert Austin refers to as "measurement dysfunction" in his book MEASURING AND MANAGING PERFORMANCE IN ORGANIZATIONS (Dorset House, 1996), a short, easily read classic that is still worth picking up. -- Chip Overclock
The application development shop management didn't feel it was a productive use of anyone's time to have to go home and sleep and eat, reproduce and what not. So they brought in cots and all the comforts of home so no one had to bother with that. While they don't do development, Gartner does that too. Hire valets and such to do all the living stuff for you so you don't have take yourself away from work.
The only time I can recall doing TDD, we started out with unit tests for everything but as time went on the managers grew upset with how long things were taking to develop and the only choice was to abandon writing the tests and just plow on.
"The first time I got drunk, I got married. The second time I bought a chimpanzee, after that I stayed sober" Arian Seid
I was once working in a company where I was given a project, but they didn't give me a deadline nor did they even ask when will it be ready. The customer was a technical person (but not a programmer) and if I said that I needed a couple of weeks for refactoring the code I got the permission to do that. Customer was happy with what I had done and I was quite happy also.
Unfortunately I had other problems with that company, so I had to leave.
Some people claim that if there are no deadlines, it won't ever get ready. Or if deadline is too big, people will invent work to fill that. I can only say that it isn't true for me. I also have experienced a project that was ready few months before the deadline. The deadline was estimated by one other developer who didn't continue with the project.
I have also experienced the dark side. Unrealistic deadlines cause panic and make the project twice as delayed as it would be without deadlines.
100% of companies that I consulted with had their cultures defined by upper management regardless of what upper management intended. One company that I did work for was all about sports competition. The entire management turned everything into a sport with points, rules, and Winners and Losers. They played tennis, golf, swimming, running, biking, and a variety of high risk sports intended to get people to chicken out. This behavior then carried on with how they dealt with regulators, competitors, suppliers, etc. Needless to say then drove the company into the ground and a few ended up in jail.
Another company had a bit of an absent minded leader who was great at starting things but not really caring how they went. This created much confusion among the ranks who discovered that starting exciting projects was a great way to get praise. Oddly enough this company did fairly well.
But my favourite was a company run by a few stodgy types who had been there and done that. This company cooked along being boring and profitable. Then the main leader got sick and was replaced by a total douchebag who was all about the testicle joke. About a year later the company cratered, but they had a fratboy good time doing it.
The companies that drive me around the bend are technology companies run by boomers though. I have been to at least a dozen engineering companies where all the senior people are in the ballpark of 60 and man-o-man they have their heads solidly planted in 1950's style engineering. Computers at best can be viewed as drafting tables with electrons. I am not only talking about the 60 year olds but even the 25 year old new engineers. They want to do things that are innovative solutions and are shot down and have solutions that a WWII engineer would barely admire implemented. This results in 40 year old engineers who work at these firms not even using tools like autocad in any thing more than a pencils and rulers on a screen sort of way. Magical.
One last company is has a leader who is all about the next big deal. This company has a bunch of employees who take themselves way too seriously.
In short if that was happening then I expect the developers would either push-back or leave. As someone who has worked in technical and management roles I can tell you that it's very short-term thinking of management to do that.
You've already identified some of the problems pushing staff like that means that they are more likely to make mistakes, they will hate you (which means when you really need them to go above and beyond if they can get out of it, they will). Also it means if they do leave you need you have a bigger hole to fill because they're working more hours and it's going to be harder to find and retain someone who's willing to work extra hours and is actually good. It also sets a bad culture so that people who are good and get a job there don't stay they leave because they're good enough to get a job elsewhere. What you're left with is the barnacles who are there for the ride or people who are there for experience and then leave.
If I was a developer in your situation I would manage upwards by note your concerns and flag them with management. I would also use metrics to support your case (e.g amount of commits of code that had bugs, hours worked, sick and stress leave taken?). I would check into health and safety regulations or workplace agreements to see if what they are doing breaks any of those rules, if it does then I would notify management and measure and report on that too.
Reporting on more things, collecting metrics and managing upwards takes time and effort but it's a good way to try to change things. Alternatively I would be looking for other jobs.