'''AntiPattern:''' ''EmperorsNewClothes''

'''Original Author:''' ''JamesPoupard''

'''Anti Pattern Category:''' ''Management''

''Click on CategoryAntiPattern to see other anti-patterns''

'''Problem'''
	*In design or code reviews, no one really understands the design but reviewers are unwilling to admit it.
	*Any criticism is quashed by other reviewers who claim understanding and consequently gain a feeling of superiority.

'''Context and Forces'''
	*Peer Review is seen as a milestone to pass before development can continue.
	*Too much negative feedback can delay development and effect project timescales.

'''Proposed Solution (the bad one)'''
	*Make design process and procedure idiot-proof to prevent developers making mistakes next time.
	*Down-play complaints about over complexity or lack of abstraction because changes can be postponed until the next stage of development.
	*Effort required to make major changes at this stage has a huge effect on project timescales. Consequently leave it as it is - it won't be as bad next time!
	*Define design or coding standards with a set of clear rules that can be tested against to simplify the peer review process and minimise non-constructive feedback.

'''Resulting Context'''
	*You cannot develop an idiot-proof process - a good process depends on good developers to execute it  (see IdiotProofProcess).
	*Delaying serious problems will lead to more serious ones (see ImplementationIssue).
	*Checking only against standards will mean any updates to design or code is simply cosmetic.
	*All of these leaves us with a poor design which means:
		*Requirements may be left unmet
		*Major problems are missed
		*Difficult decisions are left to the implementers
		*Coders ignore or abandon design
		*Design will have served no purpose
'''Design Rationale'''
	*Identify different people who:
		*have good analysis and design skills
		*can define good abstractions
		*have good implementation skills
		*or are subject matter or user experts
	*Hold regular brainstorming sessions with these people to refine requirements and/or develop the design.
	*Change organisation to promote day to day coaching of those less experienced.
	*Adopt and/or develop simple, clear notations that are more understandable.
	*Change focus so that formal reviews are a just a small part of the quality process.

'''Related AntiPattern''''''s'''
	*IntellectualViolence - used in review meetings.
	*ThrownOverTheWall - guidelines, treated as formal process and followed blindly.
	*DesignByCommittee - committee ineffectual, identify and assign correct roles.
	*TheGrandOldDukeOfYork - roles and responsibilities do not match ability.
	*IdiotProofProcess - following a strict process guarantees success...?
	*ImplementationIssue - 'perfection' delayed until implementation.
Discussion below...
----
See also TheEmperorsNewClothes