Managing Project Complexity

Name: ManagingProjectComplexity

Context: You are developing a complex system, or have inherited a complex legacy system. SoftwareDevelopmentComplexity? / ComplexityHasToGoSomewhere / AccidentalComplexity / RefactoringLegacyCode

The natural result of naive software development is mentally unmanageable complexity because software development results in AccidentalComplexity results in EmergentBehavior is often considered a defect but can be reduced by using abstractions that are handled by Heuristics which are used in Automation which is used in all software development and increases complexity(run-on sentence used to illustrate circular nature of automation problem)

Principles

1) Complexity is the enemy. 2) Development performance is directly related to the quality and complexity of the code, documentation, and tools.

3) Mental power is extremely precious 4) Refactored mud is more valuable than new code. 5) The greatest skill is finding and viewing the proper abstraction level. 6) Redundant monoliths are a suitable model for the reality of development 7) Management, development, quality assurance, and configuration management are required roles independent of headcount.

8) Users are aliens. (TeachMeToSmoke) 9) Two minds are more than twice as powerful as one mind.

10) Only understood rules should be broken


Theories

ReconciledProgramming? - Practical balancing of factors. TheyreJustRules and RulesAreMadeToBeBroken

Tactical/InterceptiveProgramming? - Programming based on "critical points" in the software

PanopticAnalysis? - Slicing a project many ways to increase understanding

ReconciledRefactoring? - Making the complex manageable after balancing with other factors

CriticalMass - Treat the "solved" system as a power plant, providing functionality, features, and a code library

TerminalComplexity? - The point at which a system cannot become more complex and continue to function.

Related: RepresentingDesignAspects BigBallOfMud AmorphousBlobOfHumanInsensitivity ExtremeHarmony DesignAsHarmony HereticalProgramming AirplaneRule

Mental Context: InTheZone, MentalStateCalledFlow


Kind of unfocused, trying to aggregate techniques for managing project complexity(not algorithmic complexity)

I suppose a page about managing complexity would start overly-complex and need to be managed!

Heading out of work, won't be doing it myself, perhaps name this page to ManagingProjectComplexity? Done.


"Refactored mud is more valuable than new code."

I just can't disagree with this statement more strongly. Just because there is code that "does something" doesn't mean the existing code base is valuable or has lasting merit. Too many times I have been dropped into a project that had all kinds of effort invested -- sometimes man years -- but had no chance of succeeding. Code that simply can't perform need not be refactored. It can be scrapped.

That's definitely debatable. See the discussion for OldCodeRusts. My point was to treat too-complex projects as a BigBallOfMud. In that context, refactoring is the only real option. Otherwise you'd have to completely rewrite a very complex project - then you aren't managing project complexity, just restarting it. So the gestalt is that properly refactored mud is valuable because it contains logic that probably evolved that way for a reasons, and because after refactoring it doesn't need rewriting.
SoftwareEngineering needs:
CategoryManagement

EditText of this page (last edited August 5, 2005) or FindPage with title or text search