Development Values

A couple of years ago, with the help of a co-worker, I put together a high level list of “Development Values and Principles” for LiquidPlanner. I was re-reading them today and thought they were well worth sharing…

Values

• Value Quality above both Quantity, and Speed of development
• Value Clear above Clever
• Value Maintainability above The Quick Fix
• Value Collaboration above Individuality
• Value Refactoring, Iteration, and Evolution above Engineering
• Value Just-In-Time above Just-In-Case
• Value Automated Testing above Manual QA
• Value Metrics above Instinct
• Value Readable Code above Comments and Documentation
• Value Small but Complete above Large and Unfinished
• Value Libraries and Components above Frameworks
• Value Containment above Inheritance
• Value MVP above Kitchen Sink
• Value Realism above both Optimism and Pessimism
• Value Thought above Action but avoid Analysis Paralysis
• Value Pragmatism above Idealism
• Value The User above all else

Principles

YAGNI, KISS, and DRY - in that order

• YAGNI - If you don’t need it, don’t do it
• KISS - If you do need it, keep it simple
• DRY - If you can’t keep it simple, keep it functionally DRY

In addition, try to keep the following principles in mind:

• Single Responsibility
• Separation of Concerns
• High Cohesion and Low Coupling
• Single Level of Abstraction

… but avoid over-engineering

Test Driven Development

NOTE: we take a sensible middle ground in the recent TDD debate by simply assuming the final ‘D’ is for ‘Development’ instead of ‘Design’ - a healthy test-suite is useful for many reasons, guiding design is just one small part of TDD.

We highly value automated testing.

• Embrace unit and functional tests
• Test-first when appropriate
• Test-as-you-go when its more practical
• Use tests to guide design (but not dictate it)
• Use tests for ensuring quality
• Use tests for documentation and communication
• Use tests as a safety net to allow for refactoring

Refactoring is the most important way to ensure long term code maintainability:

“Just because it works, doesn’t mean its finished”

Broken Windows

Always keep in mind the broken windows theory.

Sloppy, complex, code is viral, when other developers work on that code base they will have a tendency to fit into their surroundings because they cannot be sure that there wasn’t some reason for that peculiar implementation.

Having a great automated test suite gives developers a sense of trust and enables them to fix the broken windows, knowing the tests will inform them if they have inadvertently changed behavior.

“If you see a broken window - fix it!”

Software Craftsmanship vs Engineering

Start to think of yourself as a software craftsman instead of software engineer. The value you provide is measured by the quality of your craft, and NOT the quantity, or the speed of development, or predicting the future.

Encourage personal growth and pride in being a better programmer

• Code Complete
• The Pragmatic Programmer
• The Passionate Programmer
• The Art of Readable Code
• Clean Code
• The Clean Coder

Final Words…

…from the best comic on the web