Random Ramblings on LabVIEW Design

Happy New Year!

I like to think of myself as a designer and not a programmer, I also think I'm a pretty good designer and on the journey to becoming a good designer I've learnt a few harsh truths. You can learn these hard way, or I may save you some frustration if you learn them here.

Hope everyone had a stress free holiday. In the last article we discussed accounting and how that analogy applies to the software process, now let's apply ourselves to Software Design and Italian cooking..

You've probably heard of Technical Debt and it's a nice metaphor, but there are other technical accounting terms we can apply.

All the fun of accounting and none of the fun of programming woohoo!, read on.

We fairly often get called in to rescue projects that go wrong, I thought it might be useful to see the process we go through.

I've not had any business travel for ages now and am going a bit stir crazy!

It might be cathartic to look back at my last big trip and how it fitted into my rules for a more interesting life. In fact I might have come up with some more rules.....

Comic book artists have a foundation of discipline and hard work. It's a world that has a lot of similarities to LabVIEW programming ...........

As chief trouble-maker I thought it would be useful to open up about GDevCon#1 and what I feel about it, the people who made it happen, the presenters, sponsors and attendees. I'll also discuss what I liked and didn't like and discuss the implications of democratic management and how I thought that went.

I have a theory, so hear me out.

There are people who write their LabVIEW for APIs and Toolkits and there are people who write their LabVIEW for projects. Their needs and wants are somewhat different, this article explores this...

At SSDC we pride ourselves in our customer relationships. We've described our methodology and process in great detail, but there's one more secret to our way of working that helps generate pleasant customer relations. This article reveals all!

An idea regarding environmentally changeable VIs

One very useful design technique is to be able to match a diagram to code. Here I talk about our state machine design and how it's subtly different from the taught design.

This article pulls together some strands discussed here into one presentation that I gave at DevDays Galway. It essentially brings together all the techniques SSDC apply to our projects and we seem to avoid all sorts of pain because of them. It draws heavily on my writings here and were applicable I'll just link to the associated article.

We had a trip to Galway for Dev Days 2018, trip report....

We had a discussion on this at CSLUG and I presented my thoughts on a possible UI design.

Here's it in words and pictures..

I like to think SSDC are a proper grown-up company, doing proper grown-up projects with our grown-up accreditations in risky environments. So I'm offering up a new LabVIEW marketing tagline :-

"LabVIEW: it's not just for kids!"

Read on.....

I've talked about democratic management in various articles and GDevCon was an excellent opportunity to test the theory. Here's the story so far..

Revisit the points and talk about sub-repos

There is not one cure to complexity, it's painstaking attention to detail, whittling away at all those things that disturb the story of your design.

Read on..

Doing my presentation for the CLA Summit has clarified one area of dispute between me and the rest of the LabVIEW community (it feels like). It's the difference between Programming and Design.

I wasn't going to write about this year (as it's a bit repetitive), so instead of talking content and reviewing I'm going to talk people and atmosphere.

A teaser for our new book!, sometimes discussions on software design sound a bit like this!.....

A couple of jobs have come into SSDC Tower of Programming Power in the last couple of months requiring .NET integration and we've come up with a novel technique for handling it.

Read more......

Here's a bit of scripting that I lashed together to generate what we call components (what others call action engines). It's quite useful to us and the link elsewhere has gone missing.

I'm of the opinion that documenting your code can be viewed as a code smell, but some documentation I like. This article describes all.

Gather round the fire at the SSDC barn of Engineering Excellence and let's have a look at the year gone past.

Many years ago I worked for an aerospace company and it was structured in such a way that it gave me an insight into what makes a good engineer...

A little Thanksgiving gift....be thankful!

NI Employee of the month Peter Horn emailed me an interesting question the other day. It was pertaining to the LabVIEW Center of Excellence and associated processes.

To quote "I was wondering if you’ve ever measured the impact of implementing these processes – either with your own development work or customers you’ve been working with? Everything I’ve found online so far makes sense, but figuring out how to apply it to a specific account isn’t making sense to me just yet."

Now that is an interesting question.......

I modified the Modbus toolkit (some version I got off NI.com a while back) and in my normal fashion wanted to control my dependencies. All I wanted to do was to move the modbus directory from vi.lib and embed it into my project hierarchy. I also need to be able to then move my entire project hierarchy about on the drive too.

Here's how it went......

I visit a lot of companies and they all proclaim a pretty standard set of values.

Employees are important, empowerment, valued are all terms chucked around like insults at a political rally. Weirdly I see very little evidence that the majority of managers actually believe it.

Read along as I sow the seeds of revolution comrades.