'''AntiPattern Name''': ''Fear Of Success'' '''Type''': ''Organizational'' '''Problem''': Past, often ''successful'' projects were threatened by visible problems; or the same for a current project. '''Context''': Any number of fundamental disciplines can help eliminate these problems - requirements, testing, architecture, management. Managers have seen those things work in the past. '''Forces''': There is no need to "risk" another bumpy success. Managers suppose that they can drive the problem count or problem severity down to zero by simply applying ''enough'' of all of these disciplines. Whether the team ''overcame'' problems in the past is irrelevant; no risks can be taken. '''Supposed Solution''': The next or current important project must be protected from any imaginable problem. No risk is too small to add a full-time worker to mitigate it. Management creates a defensive environment, analogous to large numbers of defenders on a soccer field trying to defend the goal and never attacking. '''Resulting Context''': BrooksLaw compounded by excessive bureaucracy prevents any work from getting through the multiple defenses against "problems", or else the cost is inflated far beyond reason. For anything to get implemented, multiple people must run a gauntlet of failure-removing measures backed by hysterical pessimism and paranoia. The resulting problem varies by what kind of problem is trying to be ''solved'': * If the requirements kept changing too much in the past, the requirements must be an inch thick and signed in triplicate by the client. Developers and testers will have to spend most of their time reading and deciphering multiple forms of requirements. * If a past project used an unstable technology or had disorganized code, the system must be painstakingly architected. Developers must jump through the hoops of the inevitable huge architecture, ''supposing'' it ever gets done. * If there were too many bugs in the past, the system can never be released with any "bugs" present. Testers test early and often against whatever irrelevant details are described by requirements. Developers cope with enormous lists of largely irrelevant bugs. * If the system lagged in construction, the team size must double or triple in order to pick up the pace while maintaining BestPractice. BrooksLaw drives both cost and construction time up wildly. A ''formerly'' successful project or team bogs down under the weight of the organization. '''Design Rationale''': '''Related AntiPattern''''''s''': Every architectural AntiPattern, especially AnalysisParalysis; YetAnotherMeetingWillSolveIt; any other patterns related to inflated work '''Applicable Positive Patterns''': '''AntiPatternCategory''': Management '''Also Known As''': ---- FearOfSuccess is not just a FearCulture. FearOfSuccess is when a person who is about to win, aborts what he is doing and loses just because he thought he would lose anyway. For example, you are about to deliver a module of the system, but the ones who deliver early are accused of not being integrated with the ones who deliver at the end. There is fear to deliver and since deliver is a requisite for success, we say there is FearOfSuccess. Another example is when people use a locking version control system instead on a non-locking version control system like ConcurrentVersionsSystem. The result is that the ones who take the more time to edit their own classes block the others, so that they MakeOthersLookIncompetent. The ones who deliver late have FearOfSuccess, so they deliver late. When non-locking version control system is used, the ones who deliver early are winners, while the ones who deliver late are losers: they need to integrate their changes with the changes of the former. -- GuillermoSchwarz My first reaction to the title was that it was more of an organizational malaise. As in, an organization knows how to manage unsuccessful projects, but is terrified of not knowing what to do with a successful one. -- AndrewMccormick ---- I've always detested this terminology. It reeks of the worst kid of Motivational Speaker buzzwords. The definition above is not about being afraid of success - the fear is of various (real and imagined) threats that must be surmounted in order to succeed. While I don't doubt that there are people who are literally "afraid of success" - eg. people who are afraid of the spotlight success could put on them... but fear of a required action or potential failure is not "fear of success". ---- I found a great site on dealing with FearOfSuccess, though CognitiveTherapy http://www.coping.org/growth/success.htm ---- CategoryAntiPattern CategoryOrganizationalAntiPattern