Applying ‘12 Steps to Better Software’ to LabVIEW

[Elijah_K]

If any of you subscribe to Joel on Software, you may have come across this article where he provides a 12-step checklist for developing quality software. These recommendations are just as true of LabVIEW development as they are of any other programming language:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

In Joel’s opinion, if you can’t answer ‘Yes’ to at least 10 of these, you have serious problems with your development process that could slow you down and lead to low-quality code. I went through these with NI’s NPI process in mind and happily scored a 12.

As a LabVIEW developer, if you would like to share insights or feedback on any of these topics, we’re eagerly hoping to hear from you…

Originally posted by ekerry at http://ekerry.wordpress.com/2009/04/10/applying-12-steps-to-better-software-to-labview/

[Andrey_Dmitriev]

Thanks for posting this!

I follow almost all these steps many years, and agree, that this is one of the best description of the software engineering process.

I would like to explain - how this works for me with examples:

1. Source Control.

We using Microsoft Visual Source Safe. One great point - this SCC can be integrated with LabVIEW IDE. Works perfect for us. Also no any server installation required, because MSVSS is client-side SCC.

2. Build in one step done by build specificcations - they can be called programmatically from LabVIEW, and we have "top-level" project builder, so we can build several LabVIEW projects programmatically with single action.

3. I do builds almost every evening - calling build specs from LabVIEW makes this easy. next morning I have report - which modules are OK, and which not.

4. Bug database done with Mercury software. For small project just Excel table better than nothing as Joel mentioned.

5. Bug fix before new features - absolutely important thing! Its also important to synchronize bug fixing process with schedule for new releases.

7. Specifications - we have several "leveles". First one is MFS - Marketing Functional Specification (very high level product overview from marketing point of view). Second is SRS - Software Requirements Specification - from user's point of view. And last one is DRS - Design Requirements Specification - from Developer's point of view. Complicated projects may have multiple DRSs.

8. Sometimes its not so easy to get own room for each engineer, but its very important!

9. LabVIEW itself - great tool (and pretty expencive), so if we working with LabVIEW, then we meet this point automatically!

10 and 12. Testers (and technical writers) are very important persons! This saves huge amount of time for software engineers and increases quality of the code. But if you haven't testers, then hallway tests may be "better than nothing" alternative.

11. This point is important, but its not so easy to find "ready for use" LabVIEW-oriented engineer. So, we should be flexible - most important points for me here "be smart" and "get things done". If engineer "smart", then he will be able to learn LabVIEW during development small projects.

Also thanks for posting link to NPI process. How funny - we also have defined process named "NPI" in our company.

Andrey.