Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 
298 Views
11 Comments

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...

Read more...

212 Views
5 Comments

A little Thanksgiving gift....be thankful!

Read more...

777 Views
12 Comments

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.......

Read more...

393 Views
2 Comments

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......

Read more...

995 Views
29 Comments

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.

Read more...

588 Views
4 Comments

SSDC stands for Structured Software Design Consultants, it shouldn't therefore be a surprise that we have a pretty structured approach to the software process. We like checklists, so here's a closer look at our code review checklist.

Read more...

489 Views
0 Comments

I took the opportunity to vent my spleen in my last article, I suppose I had better explain myself.

I'll attempt here to codify my proof that LabVIEW is not easy and programming cannot be optional in the vast majority of cases.

Read more...

616 Views
5 Comments

A feisty little bloggette about how easy my job is, really really easy, optional even......

Read more...

1145 Views
6 Comments

I've been playing this game for 30+ years now and this has tempered my expectations. In fact it's made me a bit pessimistic. This is actually a good thing. Read why......

Read more...

1064 Views
2 Comments

I touched on this in my immediacy presentation, but think it needs pulling out and concentrating on. It's an easy concept, but when I've shown and described this to people they seem to get value from it.

Read on.

Read more...

1417 Views
19 Comments

Pesky humans ruin everything, this article describes how their input will knacker your programs and spoil your day. Also how to deal with them!

Read more...

1274 Views
12 Comments

This article has nothing to do with LabVIEW, but read on and it might make your life more interesting..... 

Read more...

757 Views
5 Comments

This here article is a summary of the points we were trying to get across in our NIWeek 2017 presentation that you can see in the text. Enjoy!

Read more...

1924 Views
8 Comments

I've seen a few presentations that describe coupling and cohesion incorrectly and thought it might be an idea to revisit some material I have used in training before. I think all the talk about asynchronous processes (actors) also allows us to discuss the metaphor as well.

In our book we used an factory analogy and it worked OK, I think this might be a better analogy going forward.

Read more...

903 Views
5 Comments

I sometimes feel part of the "establishment" and then I rebel against it. With regard to programming what do I view as the "establishment" and why do I think rebelling is a good thing?

Read more...

1027 Views
4 Comments

As I recover from jetlag (over-partyitus) I think I should do a review of my trip (including the fun bits and skirting over the business bits)

Read more...

916 Views
6 Comments

My output blog-wise has been poor this year, mainly because I've been making presentations. One of the side effects of the eCLA summit and NIWeek getting pushed closer together is I've lost 3 months in presentation design time.

Read more...

705 Views
0 Comments

This article is the second part of my presentation given in Vienna March 2017. It concentrates on Risks, Outcomes and Mitigating Factors.

 

Read more...

1006 Views
0 Comments

Most project failures are not failures of programming skill or technique. The blame lays pretty squarely on a failure of judgement when applied to risks. This is the blog form of my presentation for the eCLA Summit 2017 in Vienna. i.e. it's  (words and pictures) - (messing around with microphone and accidental sweariness)

Read more...

1065 Views
3 Comments

You may have missed this as it barely got a mention on NI.com. Which is strange!

Read more...

853 Views
1 Comment
1091 Views
9 Comments

As it seems like narcissism is the current way of behaving I thought it might be interesting to keep a diary for a couple of weeks. If you're ever thinking of starting a business like ours, it may be of interest, or if you are already running your own business I would be very interested in your counter-diary. I'm nosy like that.

This has not been a typical week as we've done a bit of travel, that said it's not really that atypical either.

Read more...

2544 Views
17 Comments

My personal observations (as a white male egalitarian)

Read more...

1052 Views
1 Comment

For the world I feel that 2016 was a right ugly beast of a year, for SSDC 2016 has been pretty good fun and teetering on the edge of being profitable. Here's our story of 2016.

Read more...

1145 Views
8 Comments

Often SSDC is asked to conduct design reviews and one area that this can be improved is by reviewing against a customers use-case. With this in mind I'm trying to come up with a questionnaire that will help us to understand the project requirements better.

Hopefully this will be a useful document to help weed out the nuances and maybe group-think will make it even more useful!

Read more...

1556 Views
6 Comments

Only those on the path to programming enlightment should read further. In the last couple of years I've changed my view of the world of programming. Reinforced by my conversations here. I promise there will no spiritual stuff here and very little mindfulness.

 

 

Read more...

1174 Views
2 Comments

They've only gone and given us our own NIDays track. The catchily titled "LabVIEW Power Programming with the LabVIEW Community". Find us in the Shelley Room. 

 

 

Read more...

1085 Views
6 Comments

Welcome to my century of blogs, if you've been with me since #1 then color me impressed!

Pretty much every job we do has a tight deadline and we often turn work away because the deadline is ridiculous. For example one of the jobs I'm working on at the moment has been underway for years, we've been called in 2 months before the delivery date. In these cases there is often a genuine reason (non-delivery by contractor).

Other times it's essentially because an accountant stipulates when a project needs paying. This is very prevalent in government work. Yesterday I asked facetiously if the accounts department would be using the software, because the tight deadline will effect the quality and they won't feel the impact.

Here's the thing, quality improves with time. If you remove time from a project the first sacrifice will be quality.

From an engineering perspective I've done 2 jobs that I think were exceptional. Before a £1,000,000 experiment I wrote a cRIO distributed DAQ system, experiment was booked in for Monday, got the purchase order Thursday. In another job I had 6 weeks to design, build and deliver a high-current contactor test system. What characterized each system? Nobody remembers the ridiculous/miraculous engineering effort. Everybody notices the slightly clunky and limited functionality. The contactor tester has done its work for over 10 years now and it's embarrassed me for all 10 of them!

So here's the life lesson....

You will be remembered for your quality long after the missed deadline is forgotten, only sacrifice it if you really really have to.

As this is article #100 I'd like to express my gratitude a bit.

Thanks to all of the contributors your comments have improved this blog far beyond my expectation.

The effort you put into educating, clarifying, questioning in response to my half-formed ideas is what makes it for me.

I'm probably going to go quiet over the next few months, business has got proper busy, we have 2 new ships to do, SingleShot has taken an interesting direction, I'm currently working on 7 projects and my mind is beginning to melt!

Lots of Love

Steve

1129 Views
10 Comments

Article 99!!

Here we are at the cusp of article 100, if you've endured all of them I thank you!

I've finished Peopleware and a damn good read it was too, I highly recommend it for programmers and managers, in fact anyone involved with a team.

As seems to be common practice these days I will now pick all the bits that align with my world view and ignore everything else!

One of the most important life lessons is that Software is a People-Oriented activity. There are many aspects to this and I'll skip through the ones that interest me.

Everyone is different (and that's a good thing)

This revelation has actually come from the discussions on this blog, so it's worth the admission price just for that.

The trouble with methodologies and processes is that they are designed by people who inherently like working in that fashion. This is then sold as the "best" way to work, well what's best for me is not necessarily good for you. Here's some 50/50s

Some people like comments in their code. Some hate it.

Some people like LabVIEW. Some hate it.

Some people like starting. Some like finishing.

Some like working to standards. Some find it restrictive.

Some like Unit Testing. Some don't.

Us noisy people loudly say one way of doing something is the correct way, it only really means that it works for us and people similar to us.

One absolute rule I have observed is that there are people who moan and people who do, the venn diagram of moaners and doers never seems to cross!

Be Nice

Google spent a lot of time and energy and came to the conclusion that team members that look out for each other work better, This simple cost-effective concept seems to elude groups of clever people in a fair proportion of businesses I deal with.

For people who watch The Apprentice the classic macho-manager stomping about bullying people into submission seems to be desirable. Nice people are weak and in business you need to be STRONG!!! Sigh! This way of working is idiotic, destructive, old-fashioned and childish!

Here's the thing I am really unproductive if I feel annoyed or irritated. One simple way to improve productivity is to treat me nice!

Here's another secret, people do business with people they trust and like, especially where intellect and experience is the commodity being traded

Behavior is Influential

One poisonous individual can destroy a team and damage related teams and these people who only see bad in others, the gossipers, the spreaders of discontent, the vampires of ego need isolating or removing. Sacking these people is horrible, but not as horrible as keeping them on!

If they bubble to the top of a company they affect the mentality of the whole organization, sadly this happens more often than it should.

Here's the kicker, the work we do should be fun. The things that stop it being fun are people related. Spend effort on this and good things happen.

See you for my century!

Be nice to each other

Steve

915 Views
0 Comments

Hello Risk-takers

This article concentrates on a very simple rule we apply to all our projects, it's

Identify Risk and Tackle it First

The best way to emphasize this is to describe some common scenarios.

Scenario #1 Hardware

We quite often get projects where the hardware is purchased prior to even a schematic being drawn. You then are presented with hardware you are unfamiliar, for a use-case you barely understand. So what we do first is manually get the thing running. In fact one of our standard milestones is a manual hardware screen, with this you can test the wiring, start exercising the UUT (unit under test), confront your customer with the real world.

Scenario #2 Badly Defined Requirements

Very rarely* one of our clients doesn't fully define their requirements accurately, sometimes they don't fully understand how the system goes together, how the hardware works, even how their UUTs work. So it's not incomprehensible that they can't define their systems requirements. Once again we therefore have to confront them with the real world as quickly and cheaply as possible. To mitigate these risks we use prototype screens.

Scenario #3 Payment

For SSDC we deal with approximately 5 new clients a year, some are nice, some not so much. To mitigate financial risk in the UK you can do some rudimentary checks. Websites like companycheck, DueDil are very useful for some background checks. Talk to your suppliers. Generally we make sure our hardware liabilities are paid first, so pro-forma invoices are the way to go. Define your terms (30 Days Net) and stick to them!

The standard project management approach is to do a Risk Assessment and a matching Method Statement (RAMS), while we only do these on an informal basis (some companies require them to work in certain environments) it's not actually a bad idea to think about risks.

And you should never ever sit on them and hope they go away!

Lots of Love

Steve

* By very rarely I actually mean all the bloody time.