Why Iterative Development

 

 

  • Traditionally, development has been done using a waterfall (or linear) approach:  each step must be completed before the next step is started. Requirements were all defined and tossed over the fence to the electrical, mechanical, and industrial designers. The electrical designers created a complete schematic and tossed it over to the layout team. Layout team tossed the circuit board design to the fabrication team and finally the finished hardware was introduced to the software team to apply any smarts required to make the system work.

  • This approach was the result of the simplicities of the designs and the limitations of the technologies. Circuit boards were often through-hole technology with simple processors. The software required to operate these circuits was also simple. The long lead times (weeks to months) required to manually layout and fabricate the boards argued for a slow methodical approach.

  • Now, the balance between hardware and software has shifted:  multi-layer boards are the norm, processor options are staggering, and the amount of software required to tie it together can be enormous. At the same time, advances in board layout software and fabrication have reduced hardware flow times from weeks down to days. Add to this mix the likelihood of the requirements evolving during the design/development cycle and the old approaches become inefficient, slow, expensive, and frustrating to the customer.

  • The concept of iterative development (agile) methodologies has been transforming the way software is developed. In the waterfall method all the requirements are established ahead of time and then a big chunk of code is created. With iterative development, a more manageable set of requirements is agreed to between the customer and the developers. The necessary code is quickly completed and reviewed by the customer. Feedback from the previous code along with any new requirements results in additional cycles (if necessary) until the project is complete. The constant review and feedback on the code during development, results in the final design being true the customer’s requirements (regardless of how these requirements have changed over the design/development cycle). The analogy used is the difference of trying to hit a moving target with a careful aim and guesswork compared to steering the bullet to the target.

  • These same iterative development methodologies can be applied to hardware and system design. The reduced time and cost of fabricating printed circuit assemblies makes it practical to develop hardware and systems along the same lines as software. An iterative approach allows key assumptions to be tested and provides direction during the development/design process. The customer gets to have working hardware in their hands early in the process, which makes it easier to integrate all the elements of the design.

  • Software and hardware work in tandem instead of separately, this reduces the severity of errors (and the amount of finger pointing). Issues are resolved during the process instead of having all the errors discovered at the end of hardware/software integration. The fast turn available with hardware makes it practical, and often highly desirable, to build boards optimized for trouble-shooting and debugging.

 

We feel this overall iterative (agile) approach to software/hardware/system development and design, results in a better product. Costs and schedule are reduced; changes to requirements or errors in assumptions are uncovered along the way and resolved. The product has evolved during the process instead of trying to catch all the changes at the end and repeating the entire design cycle.