A set of guiding principles for software development, applying rule of thumb over strict governance.
P1: Build in the simplest way possible (KIS).
P2: Prefer working in smaller increments, build for fast feedback, refactor as necessary. Apply the rule of 3.
P3: Be a commercial developer (consider build cost, support cost & total cost of ownership) and provide regular updates on progress.
P4: Be flexible in your approach depending on problem at hand – prototype / spike / hack for early customer or technical feedback and build solid, testable, maintainable, clean & quality code once feature/concept proven.
P5: Apply the Testing Pyramid approach to quality assurance
P6: Pick the best tool / technology / approach for the job at hand. Consider optimising for the whole; globally rather than locally.
P7: Apply 12 factor app design, with architecture emerging. Consider the *ilities, make trade-offs visible as shouldn’t necessarily design for all – see fitness function fit.
P8: Collective (collaborative) code ownership – the sum of all experiences leads to better software.
P9: Follow Robert C. Martin’s ’the boy scout rule’: leave the code better than you found it.
P10: Follow the Agile Documentation Manifesto. Prefer working software over documentation.
P11: Replace manual processes with automation – automate all the things, reduce waste, improve throughput.
P12: Be disciplined – taking shortcuts / taking on technical debt can be an option short term, but left unpaid almost always leads to poor longer term outcomes; a reduction in team productivity, cost-effectiveness and increased risk.
P13: Work at a sustainable pace, limit work-in-progress (WIP), stop starting and start finishing.
P14: Design for failure (error driven design); consider all the things that could go wrong such as hardware failures, network failures, database failures, system slowness, upstream & downstream system failures, cancellations, time-outs, non-happy-day user flows etc.