Chapter 6: Build Integrity In
What I Learned
- Perceived Integrity is affected by the customer’s whole experience of a system: how it’s advertised, delivered, installed, accessed; how intuitive it is to use; how well it deals with idiosyncrasies; how well it keeps up with changes in the domain; how much it cost; how timely it is; how well it solves the problem. The measure of perceived integrity is roughly equivalent to market share, or mindshare. If you had to rebuild your computer tomorrow, how many products would you load? If your bookmarks were wiped out, how many would you add back immediately?
- Conceptual Integrity means that a system’s central concepts work together as a smooth, cohesive whole. The components match and work well together; the architecture achieves an effective balance between flexibility, maintainability, efficiency, and responsiveness. Conceptual integrity is a prerequisite for perceived integrity.
- The key to achieving integrity is through detailed information flow, from customers and user to developers and between the upstream and downstream processes of the development team. In line with the Agile Manifesto – Individuals and interactions over processes and tools, Customer collaboration over contract negotiation.
- Refactoring and continuous improvement is of utmost importance. This is a tribute to Pat Kua after he complained that I missed out that part in my review of Clean Code. No code (or product, or practice) comes out perfect the first time we write it. We start with something that works, learn from its weaknesses, and improve on it. Pat talks about the red-green-refactor practice in TDD (Test Driven Development) which is basically starting out with a failing test (red), making it pass (green) and then making the code better (refactor). This practice can also be extended to be applied to iterations, where we have retrospectives (refactor) to figure out how we can do things better in the next iteration, etc.
- Testing – my favorite software topic of all times. Developer tests assures that the code does what the developer intended it to do. This includes unit, system, integration tests, etc. Customer tests assures that the system will do that customers expect it to do, and are run throughout the development, not just at the end. Customer tests are sometimes also known as acceptance tests. So why are tests important? Why are some people so obsessed about thoroughly testing a class or a feature? And why should they be run throughout the entire development process and not just at the end? Wouldn’t it be better if we dedicated a 50-person team of testers for 3 months after the development is done? Tests are invaluable because:
- They unambiguously communicate how things are supposed to work.
- They provide feedback on whether the system actually works the way it is supposed to – and we would ideally want this feedback as soon as possible, not at the end of the project.
- They provide a scaffolding that allows developers to make changes throughout the development process – I recently just bought Michael Feathers’ Working Effectively With Legacy Code (and I’m quite excited about it) and read the chapter on Testing and he says that tests act less like a safety net to catch you when your code goes bad, and more like a cloak that wraps around the code and keeps bad things from seeping out to other parts that you’re not currently changing.
If you are running tests manually anyway, going through the motions of making sure the system still works as it should every time you change a piece of code, wouldn’t it be great if we could turn those motions into a test and build a test suite that gets automatically run every time we check in? It turns out, we can!