Random Ramblings on LabVIEW Design

Reviewing Projects

Hello My Beauties,

I was going to collaborate with NI on some training material, but time was not my friend. The process did get me thinking tho'.

The bit I was interested in was regarding code reviews, a subject close to my heart. First issue I'd like to clarify is code reviews and design reviews are very different. Each has different aspects to them and apply to the project at different times.

Design Reviews

These can apply to 2 different stages in a project, let's call them Customer Design Review and Internal Design Review.

Customer Design Review

For many of SSDCs project this is a payment milestone and will involve a design review document, a prototype UI, requirements and a project plan.

Briefly it's how we tell the customer how a project will run, what it will look like, how we will design it and what requirements will be tackled. The Design Review document records customer feedback on all of this, any extra requirement gathered and any actions.

This is very different from an internal team design review.

Internal Team Design Review

If you have new people or contractors on your team you may want to conduct a design review on their work and this should be done as early as you possibly can. Every day you delay will have more of a cost. Here you are trying to establish how these new people are going to design their code, what frameworks or methods they want to apply, what toolkits they want to use, etc etc. You are reviewing to establish that the design is appropriate for the problem and appropriate for your team. You should also assess risk here.

Using a template that asks awkward questions is useful here. Below is a section from an SSDC template, we don't use it often because we don't need to. But it's important to have it ready.

Awkard....

For us you are allowed to stray from the established techniques, but you need to consider the consequences.

Code Reviews

Now code has been written and we want to review it, but again this comes in 2 flavours.

Customer Code Review

Sometimes we get ask to "review" a project, 99% of the time "review" means "rescue". On the odd occasion it actually means review the process can be nuanced, that is because you are reviewing for a team and a set of requirements that are not your own.

We try to understand this by asking the following questions....

And this will then guide you with the review, how does the code fit with the customers expectations is the conundrum we're attempting to solve here.

Internal Code Review

This is what most people think of when talking software reviews and to my mind can be done in 2 different ways.

1) It can be done as a Quality type review where all code is assess against a standard, usually by a quality person. These suck and are usually combative, but are sometimes necessary in certain industries.

2) Maximum benefit comes from collaborative code reviews, where you and a group of like minded individuals learn off of each other. Computer Science studies have proven this to be one of the best ways to improve your teams code.

VI Analyser is your friend here! It can do all the preparatory (boring) stuff for you.

Project Postmortem

Software companies are very bad at reviewing how a project went and this has been one of the most valuable tools for making process changes at SSDC.

We only do this on projects that have had issues and where we think a process change may be required. As an example we have beefed up our risk management based on this feedback.

These should be company confidential as you need to be free to talk honestly about a project.

Awkward Questions

Having a template or a checklist allows you to ask awkward questions and these are essential to winkling out uncomfortable truths.

I felt the need to clarify these different aspects of reviewing.

If you enjoy my blog, presentations and other nonsense why not come a spend a day with some combination of me, Fabiola, Joerg and now Brian Powell. A day with authors, accredited business owners, founding LabVIEW developers and most importantly designers of software. It ain't your average day of training.

We're planning on bringing our Pragmatic Development Workshop to Albuquerque,NIWeek, ,GDevConNA and GDevCon with tickets available very soon.