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.

It can never be destroyed.
It will destroy those who do not resist.
Its tactics cannot be copied.
It must be fought by even the lowliest

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

3) Mental power is extremely precious

Two minds are more than twice as powerful as one mind.
PairProgramming
Solve out complexity - increase efficiency.
Anything that can be automated, should be - on the third strike.
Automation increases complexity
Does automating management of automators results in a system too hard to mentally understand, or a system that reaches its terminal complexity
AutomatedConfigurationManagementEnvironments? are high level automation
UnitTests are automation
Development may be a team, pair, or group.
The developers are not superhuman.
The software needs to be understandable by everyone, including the least-skilled programmer. : Problem-Which parts?

4) Refactored mud is more valuable than new code.

5) The greatest skill is finding and viewing the proper abstraction level.

Debugging is projecting one's focus to the correct abstraction level.
Higher abstraction levels do not alleviate low-level problems
Development models and methodologies are just abstractions

6) Redundant monoliths are a suitable model for the reality of development

Modular construction.
IncrementalDelivery
No single point of failure.
Replacement tools should be available.

7) Management, development, quality assurance, and configuration management are required roles independent of headcount.

8) Users are aliens. (TeachMeToSmoke)

Developer assumptions about users are often wrong.
Users are confused, malicious, superior, or all three.
Human thought and software are not inherently based on consistent logic.

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.

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:

High level notation based on metrics
Mid level notation based on architecture design
Low level notation based on code

CategoryManagement