LabWindows/CVI brings back some memories

I was reading this post from a Test Engineer that at Lockheed Martin and it brought back some memories. Yes, I’ve been a LabVIEW guy for a while now. All my roles in R&D and marketing have been related to LabVIEW but when I interned at NI I started out in the Instrument Driver group. During that time I developed drivers in LabVIEW and LabWindows/CVI (including IVI drivers) and was amazed at how CVI made C development for test applications so much simpler. It’s wasn’t just the libraries but the functional panels and the debugging. It was then I realized that my professors forced us to use gcc for all our development just to make me miserable. Well, ok that wasn’t really it, I’m assuming it was so we really had to understand what was really going on from a memory management and other perspectives but it was clear at that point that work tools and school tools would be very different.

I haven’t used CVI in a while now but every once in a while I do like to install the latest version to see how things have changed. Thanks for the reminding me about my experience with CVI JA Varnell … I may just have to install it again on my new machine, just don’t tell anybody on my team

Back to instrument drivers, I thought I’d check to see if the last one I worked on as an intern is still up on the Instrument Driver Network and it is. Check it out (ouch 2 out of 5 rating)

Red, Yellow, Green

What does the red, yellow, green color model have to do with LabVIEW? Well the color model doesn’t but since I’ve been working on getting a project plan together for a new project in the LabVIEW team I thought I’d share a little information about red, yellow and green.

The creativity of the engineers in the LabVIEW team and also the ideas and needs of our customers seem unbounded at times. So inevitably any release of LabVIEW or a given project starts with a very long list of possibilities. As I discussed earlier, some ideas require some prototype work before we feel comfortable with what we need. An example of this would be something like the System Diagram that was shown at NI-Week this year.

Once we have an idea of what is needed the task of putting the project plan begins. This includes all the things you’d normally think of, budgeting, risk analysis, market analysis and of course feature and scope definition. It’s with feature and scope definition that “red, yellow, green” comes in. The importance of features are classified by color, you guessed it “red, yellow, green”.

Green – Required to release
Yellow – Optional to release
Red – NOT in release

Green features shouldn’t take much explanation. Yellow are features that we plan to work on but after the required green features are completed, and if we don’t get to them then we wouldn’t hold the release up for them. This makes a lot of sense as introducing features late in a release can negatively impact stability so having a bar set earlier on helps ensure consistency in planning and delivery.

Why call out Red features, things you aren’t even going to work on? Well it’s precisely because you aren’t going to work on them. Red classifications are used as a communication tool, to explicitly call out a feature for stakeholders that might have expected them or may have been a priority at one time but aren’t now.

On to making some more Red, Yellow, Green recommendations. Hope you had a good Turkey day.

Process … what is it good for?

NI has a well defined development process to release software and hardware products. Developers are exposed to some things and not to others. For example, most developers don’t really get exposed to pre-release meetings and product planning meetings that serve as checkpoints as a product goes through different stages and is ready to be manufactured (CD’s or DVD’s in the case of software as well as web downloads).

Today in our team meeting we discussed the iterative process we’ve been using. I wrote a little on this topic a few weeks ago in the context of the LabVIEW Project feature released in LabVIEW 8.0

Note: By team I’m not referring to the entire LabVIEW group. I’m referring to a specific team working on features focused on improving how people deploy their distributed applications.

The current development process is “based on” Scrum which is a flavor of the Agile process.  We’re pragmatic in our approach to development and really look at any process with an attitude of how it works best for us. One of the developers in the team tried to convey that some process really is necessary even thought the initial reaction we sometimes get when we hear the “P” word is borderline hatred. A free for all doesn’t work and he said something along the lines of that we should think of process as being “the difference between doing whatever you want and making rules that we all agree are useful to follow”. I thought that was a nice way of putting it. Now, one of my roles is that of a project manager so some level of process for me is needed just to stay sane but it is always the intent and goal of any process that is the most important thing. If those goals aren’t being met the process isn’t working (for whatever reason).

One of the reasons we’re using a Scrum and iterative development approach is that there are elements of what we’re exploring that aren’t well defined from a requirements or design standpoint and require exploration. We could go off and write a detailed spec after a number of meetings, then create a design and implement it, test it and release. Most people would say that really you go through this cycle a few times for many features. What we’ve been doing is a little different than a detailed specification up front.

We’ve defined  a number of high level areas and functional requirements. For each iteration we, really our Program Manager “Jen”, select the set of things from our list we want to tackle. Here’s an image of a PowerPoint representation of what was whiteboarded in real time to describe this during our meeting for some people at a remote office.

For early iterations we’ve created more what you could call demo scripts based on primary use cases. These are vertical slices that to work correctly require integration between the different system components. The output of those iterations has been a greater understanding of our needs, integration and validation of the systems components, and code that is more or less “prototype quality”.

After an iteration areas we then feel are now understood are treated differently. These get detailed specifications, designs and the implementation is expected to not be “prototype quality” but getting close to an alpha stage or feature complete. For areas that are still unresolved we try and continue in a prototyping mode since we need more work to get rid of the “not quite wrapped our heads around this” feeling.

As we’re now further in development we have a mix of subsystems in different states. Some are in what I’ll call “prototype and exploration” and others are in “defined and implementing”. The mix over time has changed and continues to change, being more heavily weighted to “defined and implementing” as we progress.

I’m a fan of this type of iterative approach because it recognizes that there are some unknowns and risks to any project and puts into place a process to uncover those unknowns and risks in an ongoing fashion. I’ll try and have some more follow-up posts on this topics since it has been a discussion area of late in my team.