Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Re: Reviewing Projects

Active Participant

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....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....

InternalDesignReview.png

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.

Awkward.png

 

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.

DSHPage.png

Lots of Love

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments
Member

Thanks for the post Steve!

 

I like the idea of scoring the 'project priorities' before the code review - focuses your mind on which aspects are most critical for each project. Think it would stop me looking for all of those things simultaneously and getting overwhelmed, when some of them might not even be important for a given project.

Leah Edwards - CLD
Active Participant

Welcome aboard Leah,

One step on the path to programming enlightenment is understanding that other peoples priorities are often not aligned with yours, I think just the formal exercise of asking these types of questions brings focus to this.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Active Participant

I recommend making an Inception Deck for your projects. Then review the "Trade-off sliders" before each code review.

At the top of that blog post, there is a link for you to download a PowerPoint template for your own inception deck.

 

Here is an example of the Trade-off sliders from that blog post

FabiolaDelaCueva_0-1584371083860.png

 

I have been in projects where the trade-off sliders surprise me. For example, there was one project where they would sacrifice performance (to reasonable levels) before sacrificing aesthetics. This was an exception to what we normally work on, so we needed that reminder when going into code reviews.

 

 



Opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
DSH Pragmatic Software Development Workshop

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?