Concept: Develop working code, efficiently!

All software development projects create or modify ‘code’. That (source-) code is either delivered directly or delivered after some automated steps, like compiling. Aside of writing that code, there are many other disciplines and essential steps to make sure that code is working correctly. Any mature team should have knowledge of (domain-) requirements, architecture, designing and testing; to name a few.
There are many way to combine those disciplines. Like the traditional V-Model; which often results in a quite linear execution those steps. Or agile, which uses a cyclic, incremental approach. In all cases, the basic steps are similar and have the same order, only count and size of each individual steps differs. Verification (test-execution) is ignorant of the process; it is always done after the code is made. And hopefully that code is written after the basic specifications are clear.

Even the most primitive approach will deliver ‘code’, but to deliver ‘working code’ we need more; a lot more actually. To verify the code, tests are needed. But, as a test can only prove it isn’t working; we have to build trust into test-approach too. Somehow, we have to demonstrate that no failing test implies the code is working correctly. This can result is a lot of additional work: especially when all those test have to be re-run for each code-change. This used to be typical for high-quality software. There, a failed test enforces a bug-fix and so a complete rerun of all test. This repeats until no failures are found anymore. Building that level of trust can be very expensive.

To develop efficiently, less work is demanded; as no process becomes cheaper by adding labor! So, automation is needed and a more ‘smart’ way-of-working. Integrated Agile is such a concept; this mix of Lean and Agile and Scrum best practice has shown it is possible to develop working code efficiently.
Pathways is inspired by the ATS (Automated Test Script) way of working in Integrated Agile. It shares the same concept and is enhanced with a framework to quickly adopt it. However, there is only a weak connection: Pathways can be used without Integrated Agile And it is possible to use Integrated Agile without this framework. Several projects have done so. They implemented their own framework; and still reached there effectivity goals. Actually, Pathways started as a demo, when it became to tiresome to explain the concept again and again to projects.