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.

To save you some time in your busy schedules this article can be summed up in 8 words a comma and an exclamation mark.

Before you write any code, do some research!

See.. told you.

I'll now expand it just to fill the page with words.

For the lazy engineer there's nothing worse than discovering a toolkit after you've expended blood, sweat and tears to make your own. You may not end up using it, but it will save you time. I recall a conversation with an engineer who had spend 9 weeks creating a PIC relay controller that took a serial command and closed a relay...."um you know you can buy these for $60 don't you.....".

Take my tree control example found here the google search was "tree control database", this then leads on the second part of research for a software engineer.

Learn another language

There's a lot of info and ideas outside of the world of LabVIEW so look outside the community.

As a LabVIEW programmer you will benefit from being multi-disciplinary. So you can spend all your brain-power learning 100% LabVIEW and pride yourself in the knowledge of esoteric tools and techniques from the dark cobwebby corners of the LabVIEW IDE or learn enough to be proficient, then learn how to design databases and learn enough Linux to host stuff.

The second option will allow you to tackle enterprise level solutions out in the real world.

kun amo

Steve

PS mia ŝvebŝipo plenas de angiloj

Hello and welcome to my latest L³ Ramble

If you use source code control (SCC) then Kudos to you, this then will lead neatly onto version numbering

I've seen a fair few ways that you can version your source-code and this is what we've settled on. Guess what! it's not very complicated.

For every unique deliverable item we require a version number.

So......

For our main VI we have a version number and this is linked clearly (via the comments) to our versions in SCC. Clicking on the indicator will pop-up the details

Version info can be found in SCC comments and we also stick them in VI Documentation too. If they get too wordy we can link to another file or write a specific container.

On the block diagram we just use a version constant vi.

We use embedded exes and micro-services for some our programs and these will need versioning too.

Here we see that the bugreporting dialog is an exe called by the main VI and this one is on Beta Version 1:14.

For exes it's very useful to be able to query the version from the command line. Here's the code.

Using this we can send the command line bugreporting.exe --Version and it will respond on the std_out it's version number. It won't actually load itself as this is a dynamic calling VI not the actual bugreporting screen. We use this for auto-updating.

For Realtime systems we use similar tactics, but as well as something visible on the front panel, we also need to be able to query it remotely.

Here we query the rack info for a connected server and our version constant is front and centre.

In fact this applies to all embedded targets, for example we have PIC controllers that respond in a similar fashion.

Finally for FPGA targets we just embed a couple of controls on the front panel and these are then passed up to the host.

These are updated each time they are released to the outside world and not for every commit to SCC.

Here's some practices we've observed and DON'T do ..... you may have a use case that these apply to.

I've seen CLA level work that individually version numbers each VI, I guess this is instead of a pukka version control system. Seems very counter-intuitive to me!

I don't use the individual revision history options as part of LabVIEW, to my mind it drowns you in information you don't need.

In short I want to know what version of software is being used/ reported against and then be able to trace this back to a SCC release.

So far this has worked very well for us.

Lots of Love

Steve

10-July-2017 Here's an addendum based on a project I've been called in to support.

New rule: The version of the source-code needs to be traceable from source code control to the version of the built exe. I came across a project last week where I had no clue as to what version of the source code was used to build the version of the exe.

This option was used on the application builder.

The build version was then taken from this and displayed in the title bar. This is fine for the customer, but for someone supporting the code is was essentially useless. I could replace the source-code with an entirely new set of code and all it would do is increment to the next build. 

Hello World Wide Wire Wranglers,

You may well have heard be going on about KISS and it's really an acronym that I can buy into. For those of you who have never heard it, it stands for.

And this applies to everything we try and do, but what about Realtime systems I hear you ask (you know who you are, you scallywag)

RT

Well as RT has a subset of LabVIEWs capabilities we then apply

Yes, but surely FPGA has different rules? actually it does.

FPGA

One time this doesn't apply is when you're electing a president .......

Much Love

Steve

Howdy Doody Developer Chums,

Keeping the output coming thick and fast, this article describes something I've been thinking about a fair bit in the last few months.

First of all let's describe the nuances here. I don't really like supporting software (it's boring) and supporting software with a customer breathing down your neck is significantly more difficult than writing it in the comfort of your office. Some of my worst programming experiences are when something doesn't work in front of the customer and you just don't know why.

A large part of repeat business is based on how well the software is supported. Support is judged on responsiveness, the important criteria is how quickly/cheaply you find a fault or add additional features and get the hell out of the way.

So the thing I've been saying recently is that we program slow so that we can debug fast. In fact our whole way of working is debug focused, and this suits us. Fair warning, it may not suit everyone.

We invest a lot of time on our code, look here for proof.......

Rapid Modification and Debugging, Immediacy Presentation, I'm not being critical but... (Re-use) Part 1, A Tidy Project is a Happy Project even LabVIEW Life Lessons #1 - Project Portability

All of these are ways that we spend a great deal of time on our code, that has nothing to do with solving the problem and everything to do with making life easier down the line. In fact it could be thought of as technical overhead.

All of this work is us building our technical assets and paying down our technical debt.

So that when it matters our projects are easy to maintain. In fact all of this effort is so that we're not struggling in front of a customer!

Which will lead into my next L³ article

Lots of Love

Steve

If "Delivery is All" is our mantra, "Never Be Fearful" is something at the heart of the business we wanted to build................And it's really difficult to adhere to.

I don't really buy into Vision Statements or Mission Statements but this really something we discussed when we started up. So what does it mean in the real world?

1. It Allows us to be Generous

Throwing off the paranoia that business is cut-throat and people will steal your ideas and generally screw you over allows you to build healthy, strong business friendships. If you trust your customer to look out for your interests, you're in a wonderful position. Supplying source-code, designs etc (all of which we have been paid for) re-assures customers that the code will be supported in our absence. This allows us to chase after bigger projects than if we followed a more code-protected way of working.

As we build up our own IP it has become increasingly difficult to follow this through, but we go back to "Never Be Fearful".

We share everything, processes, sourcecode, designs and we have never lost work through it.

2. Brutal Honesty/Foolishness as a Software Tool

I've talked about this in the article linked above, an article I'm proud of (it only got 1 bloody "like", so I'm obviously in the minority).

The route to a stress-free life is to tell the truth. Thinking about projects, all the stress comes from dishonest deadlines or promises that never had a chance to be kept. One thing I often say is that deadlines are fictional and have nothing to do with the engineering task in hand. If a job has 20 hours of work in it, telling me it's urgent will not make me work faster, I'm already going as fast as possible.

When I ask someone for a progress report the only useful response is an honest one. Saving face, being scared of the response to bad news etc etc are not helpful.

This is something we share with the best of our competitors too, I think it may be an engineering thing.

3. Taking Risks

Taking risks is good for your ego!

Our stories, our new skills, our favourite jobs are all closely linked to the risk associated with them. Every time we walk into a new industry, stand up to present in front of our peers, share code and design ideas we expand and increase ourselves. To mitigate these risks we plan, mixing risky jobs with easier ones.

So we may not have made shedloads of money, but we have had some great fun along the way and that's because we work without fear.

Lots of Love

Stephen the Brave

Hello Sourcecode Sweeties

Here's the second in my series of short articles, each one will be about something that we've learnt over many years of writing industrial software.

It's all about delivery.

Strictly speaking this should be #1 as it is the foundation of everything we're about.

As it's clear from the discussions here we take a rather contrary and brutalist approach to LabVIEW and project management. The reason we have the confidence to take that stance is that we DELIVER. It's actually very difficult to argue against.

And before anyone says it, we don't just do easy projects. In fact a reasonable percentage are given to us because they have gone terribly wrong (we call them rescue jobs).

I guess you'll be more interested in what the secret to delivery is.

1. Tenacity

Projects can be tough, this week I started out with 2 projects and both had hardware that wasn't working. I could have thrown my hands up in the air and got frustrated or knuckle down and solve the issues. By Friday everything was working and once again my Engineering Ego is recharged.

When a fixed price job goes wrong, the hourly rate reduces. A sound business case is to walk away from these jobs. That sucks! Try to avoid doing this.

2. Checklists

One of the best aids to finishing a project is a checklist of work, it can be ticking off requirements, or tests or even open issues. If you find yourself stalling on a project, make a list of things to do and pick a couple of easy ones and a difficult one. One of the nice things about some of the formal Agile techniques is concentrating on a manageable list of tasks in a set period of time, it's very powerful.

3. Character

Are you a starter or a finisher? Be honest do you really love the start of the project, all the fun bits are the early design and customer interaction or do you love the feeling of satisfaction you get from signing off a project.

I'm about here...

10 years back it would have been 80/20 in favour of starting, so perhaps finishing on projects improves with experience.

4. Teamwork

If you are a flakey artistic type it's likely you'll be good at starting, but poor at the more detail oriented tasks related to finishing. The cure? Find someone to do the finishing for you. This can be a colleague or even a customer. One of our customers has a vested interest in detailed testing of our code and he's really good at it. In my opinion we make a good team.

Within SSDC we support each other, so when a project becomes challenging we know that there is someone there to talk it through with. Sometimes it's just nice to have someone to share the responsibility.

5. Experience

Alluded to this earlier and research has backed up that teams that have a history of delivering will most likely continue to deliver.

So remember: people won't remember that your software is clever, your unit tests are well organised, your methodology is bang up to date, you're really highly qualified and you have fantastic documentation. But they will remember if you take a lot of money and don't deliver anything.

Here endeth the lesson

Steve

What-ho wire-makers.

Welcome to my new series of short articles, each one will be about something that we've learnt over many years of writing industrial software.

Today it's all about project portability. Time spent making your project portable is time well spent. At SSDC we like to be able to download a project onto a Laptop, Virtual Machine or customer machine from our repository and for it to work.

This means........

Keep all referenced data and libraries relative.

Remove external dependencies.

Minimise use of Instr.lib and User.lib

For us the project is a directory that wraps around the LabVIEW project containing everything pertaining to the project, source code is only one part and our projects can contain multiple LabVIEW projects.

And because we are using the directory structure of the filing system we don't use virtual folders in our LabVIEW Project. I think that may make us bad people for some reason I can't fathom.

So here's our Project

The test for portability is one of our code review items and involves exporting the repository into a clean virtual machine (with LabVIEW Loaded) and into different directories (usually desktop and \User\Public\Something or other.

Doing this has saved us a lot of hassle over the years.

Lots of Love

Steve