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.
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.
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.
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)
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.
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!
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.
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!
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!
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.
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
* 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.
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.
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
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.
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.......
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I know I said way back when that ideas are cheap until someone puts the work in. here
My gift to you (mostly NI, Alliance Partners, Entrepreneurs and customers), is an idea I've put some work and risk into. It is an also an idea I'm enthusiastic about.
The image above came from my NIWeek 2016 presentation on Shock Testing and was intended to describe the standard way organizations purchase large expensive distributed systems. Essentially you have 2 choices.
1. Purchase a turnkey system
2. Do it yourself (DIY)
Over a certain price range and system complexity the risk of DIY becomes potentially career limiting. From what I have observed it becomes harder for DIY vendors (like a certain Texas based company) to sell these systems over a certain price point. So if for example the system consists of some PXI racks full of cards and the alternative supplier offers software or even just screens and a USB slot, the "full" system will always win. I've stuck "full" in quotes because the purchaser will always settle for 80% of their required functionality. As an example for the system I have developed I've had over 5 enquiries and each time they want it exactly the same (but with a few changes).
To add insult to injury from what I have seen, the hardware purchased is inferior and lots of compromises are made on the software.
Looking at the image again you can see that the turnkey system is controlled by the vendor and in my experience they are not that responsive to change requests and are quite prescriptive when making changes and removing support. Also they are prone to takeover and business refocusing.
In short the DIY vendor finds themselves at a considerable disadvantage, but actually the turnkey vendor is not providing a good solution either.
The ideal situation is that the hardware comes with software that is easily adaptable using an industry standard language, this software could be loaded from the language vendors app store. I'm talking LabVIEW and the tools network here for anyone still struggling to keep up.
I can't believe that my system is the only example here (Singleshot High Channel Count Oscilloscope). So what else? I dunno, RF, Spectral Analysis, we're looking at any large distributed system, synchronized readings, high value hardware, replacing existing bespoke distributed electronics. Thinking caps on people.
I thought long and hard about the licensing because in the traditional world there is a value to this code, my conclusion is that I'm not a salesman and my assumption is that customers will want changes and who better to do the these changes than the designers (talking high value business here in customer accounts that you would normally struggle to get access to). When you are in these large accounts you will find extra work, we always have. Also I would never get into the companies I'm talking to without this, I probably wouldn't even get into the carpark!
So a standard BSD license, with liability restrictions.
Freeing up this bottleneck will also help your relationship with the hardware supplier, essentially your software is the enabler for selling their hardware. This improved relationship is mutually very beneficial.
This is a matter of trust, you are throwing your code to the world and trusting everyone to do the right thing. In the real world there should be little incentive for any of the parties to do anything but help each other. Obviously small mindedness, short term thinking and profiteering could cause issues. For me the worst bit is feeling disconnected from the code.
So far the experience has been really excellent. Our method has transferred to remote working.
In truth tho' it's actually not that much of a problem if you can get over the initial hurdle of being paid for development. In my case a long term relationship with an existing customer mitigated the risk of tackling the project.
What can NI (or another hardware vendor for that matter) do to mitigate the risk? They can have decent amounts of high value equipment available and maybe there is even a business case to provide a grant to pay for or contribute to the development. They will then need to resist the temptation to OWN the code, open-sourcing it will be better for everyone believe me.
A Different Type of Sales
You might be thinking that because I espouse ideas in writing and with some force that they are well thought through. This particular idea is pretty much me trying to make sense of it by writing about it (I'd say a fair few of the things I write about fall into this category!). So here goes.
I think some of the sales and marketing that alliance members/consultants and integrators do is misplaced (mostly this is aimed at SSDC). The last two large opportunities that we have successfully pursued have been where we have had something to sell, rather than where we have tried selling ourselves. In someways I think this is also more useful/profitable than selling toolkits etc into the LabVIEW community. So we are changing our model to one where we sell ourselves to solve any problem, to where we have a solution and can adapt it quickly and efficiently.
Why Open Source?
Most systems integrators are more problem solver than entrepreneur. We negotiate a price to design some code and then we design it, for us we nearly always offer up the source code to the customer. Our experience so far is that the customer is keen to engage with us at the "Trusted Advisor"* level and it's a nice start to a relationship. Also they are freaked out by someone giving something away! This fits the Open Source model much closer than other models I've looked into.
I think this is an enormous opportunity for NI and system integrators. We just need to identify the gaps in the market.
Lots of Love
* for more on "Trusted Advisor" see my comedy skit at CERN, where all is explained.