I read this in a blog on agile embedded… and it reminded me of the way some of the work I used to do earlier. A lot of that came from XP and the Spiral Model, but this is about fundamentals as to why you program. This does not mean that I don’t believe in a process oriented framework. Any development framework must consider the liability of the work done (or not done).
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
And the postcript to this…
That is, while there is value in the items on the right, we value the items on the left more.
As in any discussion it is easy to discuss the pro’s and cons of both of these columns. And this is not the case of either/or but about considering both.
The snippet above can be torn apart on how it will not enable trust in a system, and that process and systems are designed to ensure trust. A key aspect of the delivery of any system is the testability and coverage. This is a good way to develop software, but your release process, and its delivery into the marketplace where lives depend on it will decide if you/your company are going t0 exist past version 3 of the product.
Samyeer Metrani 