Applying Joel’s 12 Steps To Better Software to LabVIEW
Continuing on my theme from the last post I wanted to talk about what goes around writing great software, other than the software itself. How can you improve your coding process?
I have seen in a couple of places references to Joel’s 12 Steps to Better Software and had to look a little closer.
This consists of 12 questions and you should be aiming to answer yes to 10 or more of these.
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
Stop and have a think about these with your team, what do you score?
Now what if I told you this article was 15 years old! I find this interesting for two reasons:
- Some of these points seem quite out of date with new developments around agile methods of software development building on many of these points. There is a good article which reviews these points here.
- I still know lots of developers that haven’t adopted many of these practices.
I must confess there are differences for most developers in the LabVIEW way of working. While many techniques are aimed towards 4-8 developers working on software for hundreds/thousands of users, many LabVIEW applications are developed by individuals or small teams for internal projects where you are probably already speaking to all of the end users.
Can we still infer great tips for those teams? Let’s look at what we can do with LabVIEW to add some more yes’s.
1. Do you use source control?
If you aren’t using this now, stop what your doing and go learn about it!
There are so many resources and technologies out there. SVN is extremely popular in the LabVIEW community although I would probably recommend trying Git or Mercurial as there are more services out there available to use now.
If your interested in these try the Atlassian SourceTree client which solved my previous concerns about a good Windows client for Git.
2. Can you make a build in one step?
3.Do you make daily builds?
Builds is a funny word in the LabVIEW world as this varies from many languages as LabVIEW is constantly compiling.
The key point behind this is that you should be continuously making sure the application can run. In LabVIEW this can boil down to being able to run the application consistently, especially as if you can’t run it, you can’t test it.
I make a point of running the full application after every change worth a commit into source code control or a bug in the bug database. This saves context switching of having to go back to old features because you didn’t test them at the time.
4. Do you have a bug database?
This should be step 2 after getting your source code control set up.
If you haven’t used these before, I find them invaluable as a means of tracking the state of the application.
Not just bugs but feature requests can go in the database and get assigned things like priorities, developers, due dates etc. and it becomes where you go when you need to know what to do next.
They also typically integrate with source code control. When I make a commit I mention a bug ID in the commit message and the system links the two.
So I now have a system that tracks what needs doing, who needs to do it, when they have done it and you can even find the exact commit so you can identify what code was changed to complete it.
Again, in this world of cloud computing this doesn’t even require any outlay or time to set up. Most source code hosting services have this built in.
Bitbucket is an easy one to start with as you can have free, private projects. I use a hosted Redmine server from Planio (which costs 9 Euro/month), others use Github (free for public projects).
Go set up a trial account and take a look around. As with many things it will take a bit of getting used to but I find it a far better way to work.
9. Do you use the best tools money can buy?
I’m skipping a few that aren’t specific to LabVIEW here so we fall on the best tools.
Firstly you chose LabVIEW! I think most people reading this will hopefully agree this is a good choice, but it doesn’t stop there.
There are probably two key things with LabVIEW to consider from a hardware point of view. a) It isn’t exactly lightweight and b) It uses a lot of Windows!
You don’t want to be trying to code LabVIEW on a 13″ laptop with a track pad. Get a mouse, get at least one large monitor, preferably two and a decent, modern machine.
The extra costs will soon be recovered in productivity gains of not having to wait for the software to load a new library or trying to switch between a couple of VIs and the probe window when debugging.
Also consider this from a software perspective as well. It is difficult but try and get familiar with some of the toolkits on the tools network or LAVA forums as they could save you a lot of time over writing features yourself.
There are many free tools but even if there is a cost associated you have to factor in your time to design, develop and maintain that extra code (which is probably not the area you are expert in).
10. Do you have testers?
This is one that is falling out of vogue at the minute as Test Driven Development (TDD) is becoming popular (see my previous post) which means the developers tend to write the tests themselves. That being said it is still useful to have people available for higher level testing as well but as mentioned previously we tend to have smaller teams in LabVIEW.
I think the key point right now is to have a plan for testing. Likely this should be a mix of automated testing and having some test procedure/schedule for higher level testing.
One of my first projects at Wiresmith Technology was where this failed me. I didn’t re-test the software thoroughly enough after changes (normally only the specific section which I had changed) which meant more problems went to the customer than I would like. They all got fixed but each problem means time wasted on communicating the problem as well as affecting the confidence of the customer.
Since then I now keep a procedure for testing the various areas of the software so I can do this before I send a release to the customer which has improved my hit rate as well as saving time in the long run.
With bringing in things like this there is always some pain adjusting but pick one, push through and you will come out writing better software.
swatts
January 27, 2015Excellent points James, the only aspect I would differ slightly is having a powerful machine (I know we love our gadgets but….). It has caused us problems because often the target machine can be pretty weedy. We now develop on lowish specification machines. Obviously for FPGA projects it is slightly different (power is good!).
James McNally
January 27, 2015That is a fair argument and has caught me out in the past. Thanks for posting.
(and for FPGA I think everyone gets cloud compile licenses anyway!)
Richard Thomas
January 27, 2015I’m gonna back James and say that you should always use a powerful machine for development. If you absolutely need a weedy machine then get a VM set up that simulates a lower power processor. VMs are extraordinarily useful for all sorts of testing, from different OSs and bitness to different locales (languages) and operational stresses (memory usage, CPU starvation). I have about 30 on my computer, can’t live without them!
James McNally
January 27, 2015That sounds like a good way to do it. Do you know how the Windows licensing works for this scenario though?
Richard Thomas
January 27, 2015The same as if you bought a weedy laptop – it needs it’s own license key. With an MSDN account I have access to infinite license codes so I’m ok with any number of VMs, but I appreciate that’s not so accessible for some.
swatts
January 27, 2015I like VMs for debugging code I know works, I’m not happy to develop new software, with new hardware on a VM. It adds a layer of unknowns at a time I really don’t need them. Spent many an unhappy hour debugging issues on a VM that were not apparent as soon as I put the software on the customers machine.
Richard Thomas
January 27, 2015Excellent point. VMs aren’t perfect and some people report hardware comms issues through the piped USB etc. Personally I’ve not had many issues that I couldn’t identify and repair/workaround quickly, but it is better to avoid the potential altogether if you can.
davidpcl
January 27, 2015Very interesting blog.
I was introduced to Joel’s 12 steps by Chris Roebuck back in 2008 – It all seemed very sensible back then, and I think still holds true now – the build thing especially is a mistake I have made a number of times (i.e. attempting to build your first exe a day before signoff is more often than not a really bad idea!) so always try to ensure that an exe build spec (if applicable) is one of the first things I do for a new project and verify on a daily basis.
In terms of some of the points about bug tracking, schedule etc Joel makes – I used this Scrum tool in a previous company for both of these purposes and have not come across anything better – and you don’t necessarily have to go all the way down the Agile Scrum route to get the best out of it.
http://www.axosoft.com/
Certainly beats any rigid, usually inaccurate gant chart!
Fabiola De la Cueva
January 28, 2015Excellent blog post!
As LabVIEW Developers we are spoiled, we click that run arrow and we get things working. I think the top three things needed for a successful LabVIEW project are:
1) Source Code Control
2) Good solid test plan and if possible Test Driven Development
3) Build early and build often!!!