I recently attended a seminar on advanced instrumentation, where algorithms were heavily featured. The project pitches heavily emphasised implementation rather than analysis and design, which started an interesting discussion, and led me to think about providing some hints that we’ve successfully used over the years:

1. What do we want to achieve? This is perhaps obvious, but I’ve seen that many people do over look this step and jump into Matlab or C in order to try something out. I would urge some caution here, and suggest that you think very carefully about what you’re about to undertake before writing a single line of code. Don’t be afraid to ask your colleagues/network for advice, as their suggestions may save you months of development time. Also consider using established techniques such as, MoSCoW.

2. The specifications: After establishing the ‘big picture’, split up the specifications into ‘must haves’ and ‘nice to haves’. This may take some time to work out, but undertaking this step saves a considerable amount of time in the development process, and keeps the client in the loop. The specifications don’t need to be 100% complete at this stage (they’re always minor details to be worked out), but make sure that you’re clear about what you’re about undertake, and don’t be afraid to do some analysis or short experiments if required.

3. Algorithm design: Sketch out the algorithm’s building blocks (Visio is a good tool), and for each idea produce a short list of bullets (pros and cons) and computational complexity. This will allow you easily review each concept with your peers.

4. Test data: arrange for some test vectors data (from clients or design some of your own synthetic signals), and sketch out a simple test plan of test vectors that you aim to use in order to validate your concept.

5. Development: Depending on your programming ability, you may decide to implement in C/C++, but Matlab/Octave are very good starting points, as the dynamic data types, vector math and toolboxes give you maximum flexibility. Use the testplan and vectors that you’ve designed in step 4. However, in the case of how to best design your algorithm for streaming applications, I would say that many aspects of the algorithm can be tested with an offline (data file) approach. For a majority of our radar and audio work, we always begin with data file comprised of 10-30seconds worth of data in order to prove that the algorithm functions as expected. Subsequent implementation steps can be used to make the algorithm streaming, but bear in mind that this may take a considerable amount of time!

6. Avoid a quick fix! Depending on the complexity of your algorithm, there will be certain testvectors that degrade the performance of your algorithm or even cause it to completely fail. Allocate sometime to investigate this behaviour, but remember to prioritise the importance, and don’t spend months looking for a minor bug. Try and avoid looking for a quick fix or a patch, as they generally re-appear in the future and kick you up the backside.

7. Implementation: after verifying that your concept is correct, you can finally consider target implementation. This step couples back to the previous steps, as the algorithm complexity will have direct influence on the implementation platform and development time. Some good questions to ask yourself: Is the target platform embedded? In which case, do I need an FPGA, DSP or microcontroller? Will it be fixed point or floating point? Perhaps it will be PC based, in which case is it for Windows, Linux or Mac or for a tablet? What tools do you need in order to develop and test the algorithm?

8. Validation: Verify that your implemented algorithm works with your test vectors and that look for any difficult cases that you can find – remembering point 6.

9. Documentation: In all of the aforementioned steps, documentation is essential. Make sure that you document your results, and provide a paper trail such that a colleague can continue with your work if you get hit by a bus.