The Joel Test

The Joel Test is a classic. It’s been around for a while and is still increbibly relevant. It’s probably one of his most popular articles. I thought I would just go through each item and comment on how they apply to LabVIEW today.

Looking at Joel’s list

1. Source Control – Most LabVIEW developers are using Source Code Control these days. However based on my experience, not many of them are using it effectively. Not many have an effective branching and merging strategy. Not many know how to actually retrieve things. I see a lot of old unused VIs around and VIs with diagram disable structures everywhere, in case they want to go back. As strange as it may sound I have seen Git repositories with directories in them named MyProject_Current, MyProject_v1, MyProject_v1_withFix, etc. I also see people checking in their build folders and not separating compiled code. You also see gigantic commits with simple messages like “Made some changes”. In general, simply using Git is not the same as using it well. The question would be”Do you take advantage of Git’s power or are you just going through the motions and memorizing magic incantations?”
2. One Step Build – Today I would probably expand this to cover Continuous Integration and Continuous Delivery. They’re not binary questions, but I would ask “How long does it take from a developer submitting a change until it is validated and merged into your main branch ready for release?” and “How long does it take from the time you decide to make a release until it’s in the customer’s hands?” and “How much of each of these processes is automated?”
3. Daily Builds – This ties into the previous point about CI/CD. I would add that it is important for developers to also be able to run tests locally. This is really useful so they can get fast feedback and avoid pushing broken code. Although with current tools, daily builds are being replaced by automated systems that build on every push. So a question might be “How does it take from the time you make a change, until you can verify that your project still builds?” I would probably just roll it into the previous question.
4. Bug Database – You have to have some way of tracking tasks. I really like issue trackers. I’m not a big fan of bug databases because ideally, you should be testing your code well enough and your code should be architected such that bugs are easy to fix, so you really shouldn’t have a huge backlog of bugs. If you do that is a sign of problems. In addition to asking “Do you use an issue tracker?” I would also ask “Do you do prune your database ever?” Is it useful to have a feature request in there that is several years old? If it hasn’t gotten implemented in several years, it’s probably not that important and if it is, it will come back up again.
5. Fixing Bugs – It’s simple really. Build your house upon the rock and not the sand. If you take buggy code and add more code on top of it you will only make a bigger mess. Fix the bugs first! So keep this question as is.
6. Schedule – I’ve adopted more of an agile mindset lately, so I’m not very big on formal schedules and Gantt charts. The real question is “What slips under schedule pressure? Do you cut quality? or do you cut features?” Cutting quality is always a losing game. Do less but do it well.
7. Specs – Again, trying to be more agile, I am not really a fan of detailed requirement specs. What I am a fan of is collecting actual user stories and reviewing and prioritizing them with the customer regularly and clearly communicating when there are questions instead of making assumptions. So I would ask “How often do you meet with your customers to discuss your progress and prioritize future work?”
8. Quiet Working Conditions – Less of an issue with the current state of remote work, but open office plans were certainly not designed by programmers.
9. Tools – If you are trying to save money skimping on tools is not the way to do it. Multiple monitors, ergonomic keyboards, fast computers, the latest IDE, etc. all make a huge difference in productivity. “Do your developers have all the hardware and software tools they need to be successful?”
10. Testers – You should have automated tests. You should probably still do some manual testing for those things that are hard to catch with automated tests. Human testers will also catch usability issues. Honestly, your best usability testers are your users. If you get something into their hands and get feedback, that is the best. “Do you have a process to get frequent feedback from your users?”
11. Coding in Interviews – I do like this idea, but I wouldn’t have them complete some challenge on their own. I would have them spend a day (pay them for this) pair programming with various members of the team. You’ll learn not only their coding skills, but how well they work in a team. “Do you your coding interviews involve pair programming?”
12. Hallway Usability Testing – This is good, but I am going to say a better strategy is to get your customers involved. Their feedback is the only feedback that really counts. If all your engineers love the new feature but the client hates it, that’s not a great business move.

The Sam Evaluation.

The Joel Test is very black and white, but life is gray. So I can up with the Sam evaluation. These are not designed to be yes or no questions, but rather thought provoking exercises. As you are going through this with your team, it should raise as many questions as it does answers. The value is in the questions, not the specific answers. I want you to question the way you do things and investigate if there is a better way.

• Describe your team’s strategy for managing changes using Source Code Control. How do you clearly communicate that to the team? How do you ensure they have the skills to actually implement that strategy?
• Describe what happens from the time a developer makes a change until they can verify that all the tests pass and the application builds? How do you ensure that process is fast and repeatable?
• Describe how you take a built application and get it into the hands of your users. How do you ensure that process is fast and repeatable?
• Describe how you manage issues and prioritize your work. How are your customers and developers involved in that process? How often do you meet? What happens when you are under pressure? What gets cut and why?
• Describe your interview process. How do you verify people’s technical skills? How do you verify their ability to function as part of a team?
• Describe your bug-fixing process. How do users report bugs? How are they tracked? How do you prioritize them? How do developers fix them and release the fixed code?
• Describe your learning and continuous improvement plan for your developers. What drives that process?
• Describe your process for retrospectives? How often do you have them? How do ensure everyone feels safe enough to give honest feedback? What do you with the results?
• Describe your process for on-boarding developers to new projects. What strategies do you use to get people up to speed and contributing quickly?
• Describe your process for on-boarding customers. What do you do to set expectations?
• Describe your process for distributing knowledge across your team. How do you ensure that multiple eyes get on your code before it is shipped?

Missing Questions

I am sure there are some things missing in this evaluation. If you think of something, please let me know in the comments.

I want to improve but need some help

If you’d like advice on how to improve your software development process, we’d be happy to help you. Schedule a call and we can talk about it.