Fear Driven Development - FDD
Sponsored By
I had an interesting chat recently at a conference in the "hallway track." The hallway track is all the great conversations that happen in the hallway between sessions.
What drives your development processes? Are you a TDD house, where your tests drive development? Or, perhaps there's a chief architect who isn't a very nice person. We call this ADD - Asshole Driven Development. However, this chat was about FDD - Fear Driven Development.
Organizational Fear
Organization fear can have developers 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.
This "analysis paralysis" slows the entire project down. Every one is so afraid of the process that forward motion stops. There's a great post called "10 ways to lose a team" that covers many negative behaviors that can affect a team. Things like
- Forbidding one-on-one meetings
- Don't share information
- Implying that everyone can be replaced
- Micromanaging
All of these behaviors increase ambient fear and can cause a cloud of anxiety to loom over the organization.
Losing Your Job Fear
Other kind of Fear Driven Development is when an organization tries to get developers to stay far too late, work unreasonably hard, by implying that they'll lose their job at the sign of any problems with the project. Threatening jobs will never create a more productive team. It only perpetuates negative feelings and will always lead to people quitting. This also can cause management to believe that heroic effort is a common and acceptable part of the software development. An occasional "work push" is one thing, but if EVERY RELEASE cycle means a heroic effort at the cost of your personal relationships, you've got problems.
Fear of Changing Code
Another kind of Fear Driven Development is when your development organization (or your entire organization) is afraid of the code. Perhaps the code is older (legacy code) but more likely it's just not fully understood. It mostly works, but folks are afraid that a small change to the code could cost unpredictable side-effects. Fear of bug regressions - a closed/fixed bug coming back to life also stresses developers out.
Can you think of other flavors of Fear Driven Development?
* Photo by Stacy Brunner, used under Creative Commons
Sponsor: Many thanks to Aspose for sponsoring the blog feed this week! Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and a host of other file formats in your applications. Curious? Start a free trial today.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
Fear of not being promoted. You will not get the promotion for the next level if you cannot deliver "extra" work.
This made me realise FDD is common nowadays. How will one know if you are not yet part of that kind of organization? Its better to know before joining.
This made me realise FDD is common nowadays. How will one know if you are not yet part of that kind of organization? Its better to know before joining.
Fear of taking responsibility: "I don't want to change their code because I will be responsible of any kind of instability I may cause"
Fear of shame "I don't want to decide which approach to use because they'll shame me for wrong choice - better make Architect decide" - causes every single decision to be escalated
Fear of shame "I don't want to decide which approach to use because they'll shame me for wrong choice - better make Architect decide" - causes every single decision to be escalated
Hands down, FDD for me is developing in a code base with no tests. This is often caused by other developers being afraid of wilting tests for many of the issues you list above.
In my view, fear may be seen as an impulse for their people to grow.. but mostly in this fear-based world of problems and chaos, not where people care and respect each other and what they do. I'd prefer to grow thanks to my conscious effort, choice and inner heat, instead of fear.
What kind of learning is that that has grown on fear? What kind of memories it produces? 'Oh I learned that and that really hard way.. there were no other ways to learn/achieve this for me and I must be stupid therefore'.
What kind of learning is that that has grown on fear? What kind of memories it produces? 'Oh I learned that and that really hard way.. there were no other ways to learn/achieve this for me and I must be stupid therefore'.
I have two instances from this week...
"If you don't do this they are going to cancel our project"
and
"We put all your names on the work item report so senior management knows exactly who is working on what"
The second one basically came out as a threat.
"If you don't do this they are going to cancel our project"
and
"We put all your names on the work item report so senior management knows exactly who is working on what"
The second one basically came out as a threat.
I had a boss who would frequently yell at developers who made the wrong decision, I.e. Wrong coding approach or an inefficient algorithm. And when I say yell I mean loud where the whole workplace would go silent. The things we put up with when we need the money.
Your fear of changing code, reminded me of this today: (What programmers say vs what they mean) http://imgur.com/gallery/M5wl14r
Fear of not meeting the estimate - Sometimes senior management will reprimand or punish when work takes too long so instead the Dev team will bloat their estimates to ridiculous proportions.
I don't think any other industry suffers as much on both sides of the estimation problem
I don't think any other industry suffers as much on both sides of the estimation problem
Spot on post... Here's one "Manager in meeting". Brendan what are your thoughts on X workflow. "Brendan responds", "Manager" - hhhmm interesting, sounds good. "Manager Jack, is Brendan right?" - repeat that enough times within the team and you create fear. The manager was not capable enough or smart enough to consider an informed decision so he kept playing the team against each other. Standups & Retro's now feel like potential ambushes.Worst of all is you can't speak up and say "hey idiot, grow a brain and make a decision or get out of the way." - The things we put up with support our families! :)
At certain instances I've felt like One cannot have a opinion of his own if its not align to everyone else's . Your article is spot-on in pointing out the bureaucracy played by management in getting their employees slog hard.
The saying of 'Carrot and Stick' is what i can think of..Someday the donkey eventually decides to Chuck carrot and go for grass :)
The saying of 'Carrot and Stick' is what i can think of..Someday the donkey eventually decides to Chuck carrot and go for grass :)
Fear that if you don't do the important tasks yourself the biggest idiot on the team will get hold of them and create immense damage.
The form of FDD I'm currently facing is Fear of Deploying code - fear that we haven't fully tested the new bits well enough, that some horrendous, evil bug will crop up once the new code hits production and then a Star-Wars level catastrophe will ensue. This leads down the path of Deployment Procrastination, constantly wishing I had that 'one more day' of testing before we release. I'm trying to combat this fear by both integration better change management with GitFlow, and working towards implementing Continuous Delivery. Hopefully, I'll eventually end up at a place where I hit a button to deploy without batting an eye, knowing that our trusty Acceptance Test suite and our process have got my back.
Fear of Releasing Imperfection.
Developers who have been working on a project for weeks, months or even ( occasionally ) years can lose track of the great work that they have done.
They can see all the "mistakes" and fret over the things that they have already implemented because they were'n't "done right" ( even though, they work ).
It can be very hard to push them over the line and get them to make release 1.0.
My rule: If you aren't embarrassed by version 1.0 you released to late.
Developers who have been working on a project for weeks, months or even ( occasionally ) years can lose track of the great work that they have done.
They can see all the "mistakes" and fret over the things that they have already implemented because they were'n't "done right" ( even though, they work ).
It can be very hard to push them over the line and get them to make release 1.0.
My rule: If you aren't embarrassed by version 1.0 you released to late.
As usual, the comments are better than the post! You all are the best blog community! Thanks :)
I have a few micro and macro examples from the organization I'm leaving:
-- every-other-week announcements of "if we can't make this surprise demo next week, we're finished" produced a lot of expedient but unmaintainable design and implementation choices (plus a lot of overtime)
-- fear of somehow limiting the appeal of the technology by committing to a feature set led to a whole host of horrors, including incoherent design and user workflow as well as feature specification via dropping more checkboxes in the WinForms UI editor
-- later, we were acquired by a much larger organization, where fear of producing a quote too high to make the sale meant that the hours that should have been spent on documentation were the first thing to go
-- fear of a specific, heavyweight SCM system created a culture of leaving big blocks of unreferenced and #if 0'ed code checked in, even after we switched to a SCM system where reverts and diff viewing were straightforward
-- every-other-week announcements of "if we can't make this surprise demo next week, we're finished" produced a lot of expedient but unmaintainable design and implementation choices (plus a lot of overtime)
-- fear of somehow limiting the appeal of the technology by committing to a feature set led to a whole host of horrors, including incoherent design and user workflow as well as feature specification via dropping more checkboxes in the WinForms UI editor
-- later, we were acquired by a much larger organization, where fear of producing a quote too high to make the sale meant that the hours that should have been spent on documentation were the first thing to go
-- fear of a specific, heavyweight SCM system created a culture of leaving big blocks of unreferenced and #if 0'ed code checked in, even after we switched to a SCM system where reverts and diff viewing were straightforward
The fear of changing code hit home for me personally. There are certain places in our solution that are treated like Mordor in my organization - you don't simple walk there (that is, until it's your only option). Couple that with no unit tests and the organization is afraid to re-factor this code for fear of breakage, but they're also experiencing breakage because it's often changed without being re-factored and having automated testing applied to it. It's a very fatiguing cycle.
Fear that Microsoft will ditch the platform you're investing in.
*cough* Silverlight! *cough*
*cough* Silverlight! *cough*
Fear of Microsoft / fear of non-Microsoft (as appropriate) and most pathological - fear of "crossing the streams"; using both in one solution.
Bryan - The Internet killed Silverlight, not Microsoft. We still support it and will for like 10 years.
Good some more light is being shed on this. It's no wonder we have great amounts of burn out in older programmers as they struggle to deal with a death by a million cuts by repeated less than humane behaviour.
I was disappointed about Silverlight as well, but the web technologies have stepped up quite a bit.
I was disappointed about Silverlight as well, but the web technologies have stepped up quite a bit.
Scott,
you are joking about silverlight support. MS cannot even generate the async WCF proxies. Sorry we have a large app in silverlight and MS doesn't help enough move it forward.
Please distinguish between maintain and support.
How much did MS invest in Desktop .NET technologies (WPF)?
I'm sure that many companies must support win7 for another 7-10 years. And MS forces the new app model.
Who has a bigger fear?
Laci
you are joking about silverlight support. MS cannot even generate the async WCF proxies. Sorry we have a large app in silverlight and MS doesn't help enough move it forward.
Please distinguish between maintain and support.
How much did MS invest in Desktop .NET technologies (WPF)?
I'm sure that many companies must support win7 for another 7-10 years. And MS forces the new app model.
Who has a bigger fear?
Laci
I have seen lot FDD, and at one point start to believe that it is the only way of development. Stay late and finish or you are not going home!!! However don't you think most of these fear come from marketing team's hype they present to client with unrealistic deadline because client already "had planned" something on software you are developing without any expert timeline.
On silverlight, well I think flash is dead in same way, HTML 5 replace both of them.
On silverlight, well I think flash is dead in same way, HTML 5 replace both of them.
Wow, this post could not have come out at a better time for me. I'm in a job where this type of development has recently been getting to me. What can I do about it?
Fear of being sued, one guy who acted like a project manager who cannot even manage himself threatened the whole entire dev team that he will sue us if our work is not proper, he wanted to fire all of us, there is also senior work going to complete juniors and they are expected to get the stuff right in the next 20 minutes, there are the threats of the project being cancelled every day, the threat of you will bot be promoted, you will not get increases or bonuses and such and the best one of all, you all get demoted for one guy's mistakes, all of these puts so much stress on a team, that they slack of like no other, I had all of those in my team last year, it made half of them quite which had more stress on the team since the company didn't want to hire more people
Fear of "That last release was so bad, we're going to play it safe this time."
This leads to a slower development cycle, as estimates get padded too much, and over-engineering occurs. It also leads to a fear of doing the complicated matters, in an effort to put out a "safe" release.
This leads to a slower development cycle, as estimates get padded too much, and over-engineering occurs. It also leads to a fear of doing the complicated matters, in an effort to put out a "safe" release.
This inspirational talk, on the eve before christmas -
"... this isn't a threat, but, when projects run late it gets harder to find work for you because you develop a reputation for not delivering, and it also becomes more difficult to get backing for contract renewals."
I've always admired great strategic thinkers.
What can you do to improve the situation? I found an old VHS player in the roof and started watching old episodes of The Muppet Show... I thought, just maybe I could reach this guy through better empathy.
It's all about people skills.
"... this isn't a threat, but, when projects run late it gets harder to find work for you because you develop a reputation for not delivering, and it also becomes more difficult to get backing for contract renewals."
I've always admired great strategic thinkers.
What can you do to improve the situation? I found an old VHS player in the roof and started watching old episodes of The Muppet Show... I thought, just maybe I could reach this guy through better empathy.
It's all about people skills.
"If it ain't broke don't fix it" is hammered into everyone's mind from day 1. management and developers alike.
I have a twist on the FDD. I had a customer that would beg my team to do the development work because they were afraid of the other development group. It wasn't that my team was perfect, but we listened to the customer and tried to give them what they asked for. The other development team dictated to the customer what the code would do and how their business operation would adapt. But the customers were afraid to question the developers because they came from the head office and the pet team of senior management. Unfortunately the developers weren't bad and trying their best - they were just being squeezed on their end to meet impossible deadlines. So their only option was to dictate the requirements to the customer to meet an impossible schedule. So not only were they chewing up development resources, they were delivering a bad product on top of it.
Scrums and other forms of daily stand up meetings are all created to make FDD , but surprisly many developers still cheering up for Scrums , even though it have a lot of degrading to the team .
This is all too familiar to me. My first job after college was at an FDD-practicing company, with CIO & CEO that always resorted to fear as a primary, and often times only, motivational tool. It created a hostile working environment with developers constantly covering their a** for every single thing they do, and the morale was consistently low almost all the time.
The sad thing is, i became so used to such environment that I thought that's how software development companies are run here in the states. Everything is about the bottom line, and FDD will always get you result.
The sad thing is, i became so used to such environment that I thought that's how software development companies are run here in the states. Everything is about the bottom line, and FDD will always get you result.
When it comes to fear of breaking code, it's one of the reasons I love C# so much. The type safety net lets me completely trash a giant code base and still have it come back to life easily. I've done it dozens of times and I'd be terrified to do it in something like JavaScript or c++.
Fear of < 100% Uptime.
Nevermind that 100% is ridiculous, nevermind that we have 3rd parties that stand in for us during downtime. Any change that generates downtime is looked at as poisonous to the continued survival of the business. It leads to incredibly unhealthy maintenance routines.
Fear of the customers.
"Our customers are all idiots. They won't understand this so we can't do it." Really? Then your customers will -always- be idiots. Anyone with any sense will flee your products like the simpleminded plague that you make them.
Nevermind that 100% is ridiculous, nevermind that we have 3rd parties that stand in for us during downtime. Any change that generates downtime is looked at as poisonous to the continued survival of the business. It leads to incredibly unhealthy maintenance routines.
Fear of the customers.
"Our customers are all idiots. They won't understand this so we can't do it." Really? Then your customers will -always- be idiots. Anyone with any sense will flee your products like the simpleminded plague that you make them.
Scott, please remember the lack of Silverlight support in both Windows RT and the "modern" version of IE in Windows 8. And contrast that with Flash support. In return I'll assume the end of Mac+Chrome Silverlight support can be blamed on Google, even though NPAPI support has yet to be removed by Google.
Now, back to FDD ... :-)
Now, back to FDD ... :-)
Like many people have stated above, the fear of the deadline is very much there in my organization. We seem to be moving from one deadline to the next. Chasing the next product delivery date and in theory, though with every version of the software, we are supposed to get better, we end up creating more of a mess. But it's hard to sell maintenance or refactoring to clients and so we are stuck in this vicious cycle. FDD rules!!!
Fear that I will not be given enough time to do things without compromise with my way of work.
Fear to give ideas because some older colleague or manager will say after hearing only few words : "Oh no that's stupid, that's impossible, the manager will not accept it."
Fear to give ideas because some older colleague or manager will say after hearing only few words : "Oh no that's stupid, that's impossible, the manager will not accept it."
I have a story of "Fear of Changing Code." I worked at a government contractor where it was forbidden to modify code when you could instead merely add to it. Supposedly it was less risky and required less testing. So imagine a simple condition like:
if(a)So when a new requirement came down requiring something special if a and b are true, instead of doing this:
do1()
else
do2()
if(a && b)you had to copy and paste the entire block, then add a new condition. This way you do not modify the existing code. So it becomes:
doSpecial()
else if (a)
do1()
else
do2()
if(b) {
if(a)
doSpecial()
else
do2()
} else { // not b: code unchanged
if(a)
do1()
else
do2()
}Slightly redundant, but no big deal, right? But that meant every new condition doubled the number of lines of code. I found an if statement that was literally thousands of lines long because of years of this duplication! The code was indented so far it required scrolling horizontally to see the conditions! I created a truth table and rewrote the if statement to be <100 lines. Then they explained the rule to me.
Fear of not innovating enough, not providing the great-enough new features to convince customers to pay for an upgrade.
The FDD I run into is more about project creep. So many, "What if they eventually want to do x" and "What happens when they say can we fold in y?" Because they always do. So you end up over abstracting and creating much more work partly by over engineering and partly by all the crazy ideas you end up putting in their heads before you've even opened VS.
PS. I always enjoy you Scott, I love your articles and presentations but it was MS that killed Silverlight. We had solid solutions built and bought into that HTML5 and fancy javascript are not replacements for. Not even bad replacements. MS made quite a few of us look like jerks when they killed SL. Ending development is the same as killing it. I hope we can still be friends though. :)
PS. I always enjoy you Scott, I love your articles and presentations but it was MS that killed Silverlight. We had solid solutions built and bought into that HTML5 and fancy javascript are not replacements for. Not even bad replacements. MS made quite a few of us look like jerks when they killed SL. Ending development is the same as killing it. I hope we can still be friends though. :)
I often have fear of publishing even the tiniest open source project to github. Like if I publish something people will look at it immediately and think the code is crap, and it will take up all my time.
Fear of helping others.. "I don't want to help others to fix a problem because I will be responsible for that problem.."
Usually followed by Fear of taking responsibility: "I don't want to change their code because I will be responsible of any kind of instability I may cause"..
Usually followed by Fear of taking responsibility: "I don't want to change their code because I will be responsible of any kind of instability I may cause"..
Just had a project where the fear was breaking unknown code where the developers had left, there was no documentation, the other developers on the project didn't know how the code worked. Could have re-written the app in up-to-date code for the same amount of time I spent trying to dig through it line by line in the debugger trying to make sense of it all.
Ugh...
Ugh...
I am currently battling FDD syndrome here that there never is enough time to do things "properly". Management are fearful of anything that seems to take longer than they believe it should and developers have caught on that getting things done now trumps everything else.
They also then wonder why they have so many "outages". I think you can feel my eyes rolling right now.
FDD is real and lives among us.
They also then wonder why they have so many "outages". I think you can feel my eyes rolling right now.
FDD is real and lives among us.
Hehe, I worked once at one of those companies where "everyone can be replaced" - though it wasn't implied, it was openly stated. There were also bad leaders. In retrospect, it seems it was plain arrogance that caused all the trouble. I did a write up here - I think it's quite similar to your perspective.
Fear of being caught!
Occasionally I find myself worrying about the perceived level of work. Does the person at the next desk think I'm just chilling when I'm reading technical blogs? Does the boss? In the past I have let myself jump into coding before I was ready because I felt my coworkers (non-coders) thought I was spending too much time looking for the optimal solution to a problem.
Occasionally I find myself worrying about the perceived level of work. Does the person at the next desk think I'm just chilling when I'm reading technical blogs? Does the boss? In the past I have let myself jump into coding before I was ready because I felt my coworkers (non-coders) thought I was spending too much time looking for the optimal solution to a problem.
Fear of truth - specifically when you come to the realization that your current trajectory is a train wreck and the needed course corrections are outside of your ability to affect.
haha yeah i had all of them but also on recent boss whom held my expired visa over me to keep me coding, though i did charge him extra for that...
I worked once in a company in charge of the maintenance of a huge project for a telco company. The programs were 15 years old, build for 5 years followed by 10 years of evolutions. It was IBM mainframe technologies with COBOL programs and DB2 database. When I entered the place it was hiring 100 persons, all coming from two big consultant mother-companies. Half of them were young & fresh engineers coming out of their schools. The rest was old experienced tech guys placed there because they could not be sold elsewhere. They were kept "in the closet" as we say in France.
The place was driven by fear and violence. The youngsters were taught their profession the hard way by threats and strict orders. Two special managers, young ladies, were in place because of their particular sense of bully and lack of total human qualities and empathy.
The old ones were maintained here by fear to lose their jobs. Near their offices, in the corridor, you could smell alcohol from the Thursday mid-day until Friday evening. It was tolerated to buy peace.
The telco client was quite satisfied of the result. The bosses made big money by selling the company years later.
That was the saddest place I ever worked in.
"Behind every big fortune there is a crime". Honoré de Balzac
The place was driven by fear and violence. The youngsters were taught their profession the hard way by threats and strict orders. Two special managers, young ladies, were in place because of their particular sense of bully and lack of total human qualities and empathy.
The old ones were maintained here by fear to lose their jobs. Near their offices, in the corridor, you could smell alcohol from the Thursday mid-day until Friday evening. It was tolerated to buy peace.
The telco client was quite satisfied of the result. The bosses made big money by selling the company years later.
That was the saddest place I ever worked in.
"Behind every big fortune there is a crime". Honoré de Balzac
A short post, but touches a very important topic - 'Programmer psychology'.
There is a plethora of literature on stuff like design patterns and software design methodologies, but they never cover or make mention of 'Programmer psychology' and how it affects the end product.
I totally agree with you. One important aspect which I want to point out is 'guild driven development' which I would say is part of FDD. With the recent explosion in tools that can 'impose standards' and find faults with your code, I have observed a trend where a developer is expected to write code which will satisfy all the standards and best practices anyone has ever know; disregarding the time and money aspect of doing such a thing. It is assumed that it is the moral responsibility of a developer to write code which satisfies all standards and best practices, irrespective of the time given to him !
And yes .. did someone mention about 'Zero defect' requirement !
There is a plethora of literature on stuff like design patterns and software design methodologies, but they never cover or make mention of 'Programmer psychology' and how it affects the end product.
I totally agree with you. One important aspect which I want to point out is 'guild driven development' which I would say is part of FDD. With the recent explosion in tools that can 'impose standards' and find faults with your code, I have observed a trend where a developer is expected to write code which will satisfy all the standards and best practices anyone has ever know; disregarding the time and money aspect of doing such a thing. It is assumed that it is the moral responsibility of a developer to write code which satisfies all standards and best practices, irrespective of the time given to him !
And yes .. did someone mention about 'Zero defect' requirement !
So I saw someone mention continuous development. But bad management can pervert and good concept. I have a fear that a continuous development and release will just be an excuse to always have the fire drill mega hours mentality.
http://ask-beta.slashdot.org/story/14/09/17/0035238/ask-slashdot-have-you-experienced-fear-driven-development
Sometimes fear is self-imposed. I know personally, I fear releasing bad code (whether it has a bug, or just simply isn't useful/usable for the intended purpose), bad specs, and so on.
I know I can "do it right" if I try hard enough / spend enough time on it. I hold myself to a high standard of quality and ultimately my fear comes from from fear of not meeting that self-imposed standard.
Problem is, as I become a better programmer, that bar keeps shifting higher. I've been in industry for almost two decades now, and I'm still learning better ways of doing things. That keeps raising my internal bar. But, if I hold off on a release to the rest of the team too long, I hold them back. Truth is, my output was fine (perhaps excellent even), before I raised my own bar. So, that adds a second fear that is in direct tension with the first: fear of being the bottleneck.
Both of those are intrinsic fears, not fears due to extrinsic factors. To address those, I have to keep reminding myself that it's better to release something to the team with a bug or a limitation and fix it in an update than it is to keep delaying in an attempt to perfect it. No one will think less of me for the occasional bug, and everyone will be more productive with a steady, predictable stream of updates.
I know I can "do it right" if I try hard enough / spend enough time on it. I hold myself to a high standard of quality and ultimately my fear comes from from fear of not meeting that self-imposed standard.
Problem is, as I become a better programmer, that bar keeps shifting higher. I've been in industry for almost two decades now, and I'm still learning better ways of doing things. That keeps raising my internal bar. But, if I hold off on a release to the rest of the team too long, I hold them back. Truth is, my output was fine (perhaps excellent even), before I raised my own bar. So, that adds a second fear that is in direct tension with the first: fear of being the bottleneck.
Both of those are intrinsic fears, not fears due to extrinsic factors. To address those, I have to keep reminding myself that it's better to release something to the team with a bug or a limitation and fix it in an update than it is to keep delaying in an attempt to perfect it. No one will think less of me for the occasional bug, and everyone will be more productive with a steady, predictable stream of updates.
This sounds so much like my friend K.'s job at Interactive Intelligence's Pure Cloud development center in Durham, North Carolina. In addition to all the FDD symptoms you describe, the top management insists that everyone is on HipChat all the time and penalizes workers who don't instantly respond to chat messages. Apparently, top management throws fits regularly and fires workers capriciously to keep everyone else toeing the line.
Fear Driven Development - or better Terror Driven Development - describe exactly my experience with my previous job!
A company whose core business was online trading, despite my lack of knowledge in the field wanted ME, that i did mostly web integration and flash at that point, as a dev.
They sugarcoat it at first and,since was unemployed for a while with check running out, needed to work to pay my rent and my living since wifey was unemployed too.
Then they revealed their true face. The place had a very high turnover rate, as you can expect, despite that out of need i managed to stay there two years!
Had to pratically build the whole site, style the forum, install a multi-user blog, create the back-end for their sign up system -that had to integrate with SOAP with the platform and MS-SQL while the site was written in PHP/MYSQL, had live feed of streams on pages, lot of flash, video tutorials, a wiki, etc. AND also had to take care of graphics; the icing on the cake was that i had to administer all of it.
Requirements changed daily, sometimes affecting core features, manager literally breathing on my neck, for the next two years had to work 12 hours per day and even weekends and holidays to finish that thing.
On salary.
Reduced.
No vacation.
Questioned gestapo-style for every absence and scolded for every lateness, even of minutes.
Got screamed at every time a bug happen or a subscription appeared incomplete;
the boss, a micromanaging condescending figure required from me omniscence, complaining that every time i asked for feedback and more explaination.
At the end after i mostly finished all the work and platform was reliable enough got laid off. While still US in crisis. Despite having no more income for me and wifey felt relieved not to be there. While indeed this job had a strong influence and helped me doing the ropes for being a Dev, i would rather starve not to find myself in the same condition again.
Using a pseudonym because the owner of this company was pretty paranoid and used to google itself and employers for every reference: it also caught me one day updating my resume!
A company whose core business was online trading, despite my lack of knowledge in the field wanted ME, that i did mostly web integration and flash at that point, as a dev.
They sugarcoat it at first and,since was unemployed for a while with check running out, needed to work to pay my rent and my living since wifey was unemployed too.
Then they revealed their true face. The place had a very high turnover rate, as you can expect, despite that out of need i managed to stay there two years!
Had to pratically build the whole site, style the forum, install a multi-user blog, create the back-end for their sign up system -that had to integrate with SOAP with the platform and MS-SQL while the site was written in PHP/MYSQL, had live feed of streams on pages, lot of flash, video tutorials, a wiki, etc. AND also had to take care of graphics; the icing on the cake was that i had to administer all of it.
Requirements changed daily, sometimes affecting core features, manager literally breathing on my neck, for the next two years had to work 12 hours per day and even weekends and holidays to finish that thing.
On salary.
Reduced.
No vacation.
Questioned gestapo-style for every absence and scolded for every lateness, even of minutes.
Got screamed at every time a bug happen or a subscription appeared incomplete;
the boss, a micromanaging condescending figure required from me omniscence, complaining that every time i asked for feedback and more explaination.
At the end after i mostly finished all the work and platform was reliable enough got laid off. While still US in crisis. Despite having no more income for me and wifey felt relieved not to be there. While indeed this job had a strong influence and helped me doing the ropes for being a Dev, i would rather starve not to find myself in the same condition again.
Using a pseudonym because the owner of this company was pretty paranoid and used to google itself and employers for every reference: it also caught me one day updating my resume!
As someone who's flipped-flopped between development and management roles for the last few years, I try and see both sides of this.
There are lots of examples in these comments from people who have experienced badly managed teams and projects, but few explaining what a well-run project or team looks like. Is that because nobody has ever worked in one or that they will moan whatever the arrangement is? What have people done to try and fix their situations?
Maybe the job market is different in the US, but in the UK, certainly in the big cities, talented developers can name their own price. If you're in a bad situation, have tried (constructively) to improve it but you're not being allowed to, then leave.
I think people are also neglecting the fact we live in a fear-driven world. There are plenty of industries at the moment where if that feature doesn't ship on time or if customers slam you in reviews because what you released is buggy, then companies will go out of business.
Too many developers seem to feel that they should be insulated from this and be allowed to develop as they see fit, in their own sweet time. In what other job are you allowed to behave like that? Grow up.
There are lots of examples in these comments from people who have experienced badly managed teams and projects, but few explaining what a well-run project or team looks like. Is that because nobody has ever worked in one or that they will moan whatever the arrangement is? What have people done to try and fix their situations?
Maybe the job market is different in the US, but in the UK, certainly in the big cities, talented developers can name their own price. If you're in a bad situation, have tried (constructively) to improve it but you're not being allowed to, then leave.
I think people are also neglecting the fact we live in a fear-driven world. There are plenty of industries at the moment where if that feature doesn't ship on time or if customers slam you in reviews because what you released is buggy, then companies will go out of business.
Too many developers seem to feel that they should be insulated from this and be allowed to develop as they see fit, in their own sweet time. In what other job are you allowed to behave like that? Grow up.
That is how most things work here. Managers promise heaven to clients without considering the ground force. Ground force is forced (in many ways) to deliver without testing (no unit test cases, no comments, duplicate functions, ever evolving domain model..so on so forth)...nothing new here...FDD is here to stay, offshore.
Living in a fear-driven world isn't a fact; it's a choice.
Neither my world nor my dev job is fear-driven. That's not to say it's paradise, but it comes pretty damn close to how it ought to be. Team and management supporting each other, insistence on work-life balance, and creative/generous compensation and benefitting are all hallmarks of where I work. It CAN be done the right way, and it CAN result in a dev department that wins awards and gains trust in the company for competence and productivity.
I've lived both sides of that choice; in fact, I just came from a fear-driven situation. And I'm not ever, EVER going back.
Neither my world nor my dev job is fear-driven. That's not to say it's paradise, but it comes pretty damn close to how it ought to be. Team and management supporting each other, insistence on work-life balance, and creative/generous compensation and benefitting are all hallmarks of where I work. It CAN be done the right way, and it CAN result in a dev department that wins awards and gains trust in the company for competence and productivity.
I've lived both sides of that choice; in fact, I just came from a fear-driven situation. And I'm not ever, EVER going back.
I have submitted this article to slashdot.
Read more interesting comments there:
http://ask.slashdot.org/story/14/09/17/0035238/ask-slashdot-have-you-experienced-fear-driven-development
Read more interesting comments there:
http://ask.slashdot.org/story/14/09/17/0035238/ask-slashdot-have-you-experienced-fear-driven-development
So familiar. FDD is everywhere in any Japanese companies, even the one not in Software Engineering field.
I believe FDD is also commonly connected to ADD. Would be nice to hear your thoughts are on ADD too.
I've worked in organizations where "LOSING YOUR JOB FEAR FDD" is so normal that new developers assume that's the way to work and that's how their path is going to be.
Comments are closed.
In addition, fear of the unknown leads to over-engineering. It's quite a curious occurrence to mix poor planning _and_ over-engineering. It sounds impossible, but it results from focusing on the wrong things.