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