Talk:Analysis paralysis/Archives/2014

Duke Nukem Discussion

I've removed the Duke Nukem section and Criticism section from the article completely. Wikipedia is for citing research and public information. Please debate a video-game company's project strategy elsewhere; this is not the place. In the future, if you want to cite articles that directly discuss analysis paralysis in relation to the game's development that is fine. "" 64.46.26.145 (talk) 20:08, 26 January 2014 (UTC) Stephen

Unless there is a single source that can be cited for this article then the criticism section should remain. I am a professional software developer and the fact is this article is untrue. If someone wants to edit the section to be less POV or w/e that is fine. But again, this article is untrue, misleading, encourages bad practice in software development, and DOES NOT CITE A SINGLE SOURCE. The entire article should be removed. Just because 'Analysis Paralysis' sounds catchy and may make a poser sound like a professional does not make it a valid concept. Even the example given is contradictory.

First, starting development before requirements analysis is complete is a bad practice. Without requirements multiple developers will often work to different, sometimes contradictory, solutions. There is also no way to test against a set of requirements that does not exist making all testing subjective (and therefor invalid). Without requirements there is no way to determine if the design matches customer expectations until after it is complete (and too late for changes).

Second, starting development before requirements analysis is unprofessional. There is no way to prove you've met contractual obligations without formal requirements and if the customer is not satisfied then you've exposed yourself to a fraud lawsuit (even if the implementation is perfect). While projects may get stuck on this phase that is not an excuse for starting development without requirements.

Take the example given above: Duke Nukem Forever had no clear requirements before development began. To blame this on 'analysis paralysis' makes no sense as they never produced formal requirements in the first place. Instead, they skipped the requirements step, went straight to development, and the project went into 'development hell'. The example given actual undermines the premise of this article.

Please explain how this article can repeatedly be reverted without anything in the talk page? There is not a single source cited. How are the facts put in the criticism section any less valid then the rest of the article? Applying the business term 'Analysis Paralysis' to software engineering makes no sense! I spent an hour rewording my criticism so that it would stick to facts and not sound like talk. Meanwhile, the entire rest of the article is all talk without a single source cited to support it. How is my criticism any less valid then the rest of the uncited article? Why is it that every time I try to participate on wikipedia I get shut out by fascist moderators who think that because they spend more time trolling this site that they are correct? Again, there is not a single citation to support the article and the criticism section is logical, clean, and valid. If you want to remove the criticism section how about citing a single academic source? Please stop vandalizing this article. — Preceding unsigned comment added by 173.79.251.253 (talk) 22:03, 3 January 2014 (UTC)

I am thinking this over. How about "agile chaos"? Sacrificing analysis requirements, coordination and metrics will result in resource and time waste, wait times, guaranteed deviation from expectation, inconsistency - up to inability to provide timeline changelog in case of a failure. This is quite fitting, even with Anachronox. 77.180.178.138 (talk) 04:43, 3 February 2014 (UTC)

Agile vs Antipattern

"Analysis paralysis is an example of an anti-pattern. Agile software development methodologies explicitly seek to prevent analysis paralysis by promoting an iterative work cycle"

I consider this sentence to be false. Agile software approach is opposite to analysis paralysis. BUT, Agile method has exactly same chances to cause Antipattern, because instead of research of available patterns, in-place invention might take place. I think, the formula of optimum is searched here, and its mentioned prior as price of analysis of successful approach must not exceed profit from this approach. — Preceding unsigned comment added by 77.180.178.138 (talk) 04:35, 3 February 2014 (UTC)