Principles and
Practices
Definition of Principle
A fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning.
Definition of Practice
The actual application or use of an idea, belief, or method, as opposed to theories relating to it.
Having delivered a fair amount of software, I can identify some of the essential principles and practices that, in my opinion, translate to successful software:
If It isn't Tested, It's Broken
This Bruce Eckel quote reflects the importance of code coverage through testing. Embed TDD in the ways of working for anything and every part of the system. These test suites can run locally and must be part of an automated CI/CD pipeline.
Iterate Small and Frequently
Continuous Deployment is our go-to approach to product delivery, promoted by small and frequent changes. It creates a safer, sustainable way to ship software. It also supports Continuous Improvement processes. Invest in automating any repeated process.
Make Informed Decisions
Measure and gather feedback from users, monitor and observe systems, measure product performance and cost, learn from others and use this data to make optimised decisions. Data creates a competitive advantage.
The Boy Scout Rule
This analogy quoted by Robert C. Martin (Uncle Bob) summarises the idea of cleaning up your code (assumed covered by tests) when there are opportunities to do so. Be thoughtful and focus on trivial technical improvements; avoid the risk of going down a rabbit hole. Treat significant changes differently as they require longer lead times.
Write Clean Code
Write code that others can read and understand, code that is easy to maintain. The best code is the one that extracts complexity into something simple to follow. Please keep it simple, don't over-engineer to favour flexibility or performance over cleanness unless there is a proven bottleneck.
Fix Problems That You Understand
Systems, at some point, will break or behave unexpectedly. Systems comprise an immense amount of various dependencies, including OS, third-party libraries, hardware, etc. There are things that, eventually, could escape our control. If it happens, understand the problem, create an automated test, fix the root cause and document it if necessary.
Don't Build Software, Build Product
Be pragmatic and favour product vs technological mindset. We are not building to satisfy a fictitious demand. Build to meet real user needs, be passionate about Product, create a great user experience, think about business impact towards building solutions and use mature enough technologies to bring that user experience to life.
Standardise Everything You Can
Standardise documentation, content guidelines, environments set up, including configuration, infrastructure, logging, coding standards, ways of working, processes, etc. Consistency pays off by reducing ambiguity, increases productivity, therefore, teams' performance.
Be Exceptional at Writing Documentation
Document everything that's needed. You do some of it already; your tests are living documentation, and code must be mostly self-documented. In addition, create internal documentation about the team, domain, project, APIs, architecture, decision records, hiring & onboarding, references, etc. and external such as APIs and customer documentation. It must be clean, concise, well-structured, localisable, accessible, branded and consistent.
Help Others
When working with others, you work towards the same goal. Help people, unblock them, take time to mentor, share knowledge, collaborate, volunteer, be an active member, work to make a difference. People are first, always! Create a winning culture of engagement, cohesion and trust.