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.
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?
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.
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.
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.
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.
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!
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.
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.
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.
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 .......
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.
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.
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.
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 Problem
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 Opportunity
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.
The Challenge
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
Steve
* for more on "Trusted Advisor" see my comedy skit at CERN, where all is explained.
Sometimes your manager is away from you for extended times, so how can we maintain your motivation and self-esteem levels suitably low?
Introducing the SSDC VI Criticizer.
In aggressive mode.
Or you might prefer Passive Aggressive mode.
Using machine learning technologies, IoT, big data and other stuff we have designed a revolutionary heuristic ego reduction algorithm that will rip apart your design choices, style and technique.
And we all know engineers with low egos work harder and charge less.
I'm full contrarian mode now but rather than just dismiss the arguments out of hand think about your own experiences, you may find I'm not so contrary after all.
The caveat on this discussion is that at SSDC we do not repeat many projects, stepping away from the test arena has made our world a more varied place, less friendly to re-use.
Way back in article 28 I trashed the traditional way re-use is taught/advertised in the LabVIEW world in this article here.
Our technique of keeping everything in the project works very nicely for us over all of our 100+ active projects. Issues are extremely rare. But our evolved practice still puts us at odds with traditional programming best practice in one area.
Looking at the traditional view of reuse and to clarify I'm speaking about planned functional reuse here. Planned functional reuse differs from ad-hoc (opportunistic reuse) in the levels of effort expended by teams to manage the reuse library.
"Planned reuse — This involves software developed with reuse as a goal during its development. Developers spent extra effort to ensure it would be reusable within the intended domains. The additional cost during development may have been significant but the resulting product can achieve dramatic savings over a number of projects. The SEER-SEM estimation model shows that the additional costs of building software designed for reuse can be up to 63 percent more than building with no consideration for reusability." D Galorath
Computer Science books tend to say that good practice is to manage a reuse library of highly reusable components with your team, these are tested, documented and approved. We also bend our architectures into a shape that will allow us to plug in reusable components. Finally we have to maintain this library across new versions of the software, operating system, hardware etc etc.
As a consumer of the reuse library we have to trust it will work in a new environment, giving 100% functionality (or allowing us to extend functionality).
So how many programmers have I met that enjoy maintaining a reuse library and all the effort that entails? Let me count them on the fingers of zero hands!
All of these measures of efficiency have been focused on software languages that take a considerable effort to add functionality, how does working in an environment like LabVIEW change this dynamic?
Thing is LabVIEW is rapid, I can hand crank a driver in very little time, I know it is 100% of what I need (and no more). Because it is stripped down, I'm not lugging a vast weight of unnecessary functionality with me. Multiply this by 20 pieces of hardware and it's probably a significant size improvement, which is a bonus.
The argument against this point of view is fairly strong, a reused component should be better tested, more stable, better understood etc etc. Well this is possibly true if you work in an environment where you are churning out variants of the same project. My response would be, if this is the case branch and adapt the entire project.
In the past I really bought into the whole reuse thing, investing a significant effort in pulling out useful stuff and maintaining a repository. I don't even know where it is any more, it's all a bit sad. I wonder how many man-hours have been wasted on reuse libraries full of old code for obsolete hardware on out-of-date versions of LabVIEW.
But sure Stevey, a company as awesome as SSDC must reuse loads of stuff, is a question I've never been asked. If I was, I would say YES we reuse entire project templates, documentation, methodology specific templates. Where we have identified projects that will have possible repeats we generate a project template. I view this as architectural reuse rather than functional reuse and it's an amazing time saver, standard enforcer and competitive advantage. Pretty much everything else is ad-hoc and unmanaged.
ooooooh controversial, hope I've rocked your worlds.
Lots of Love
Steve
"Code reuse results in dependency on the component being reused. Rob Pike opined that "A little copying is better than a little dependency". When he joined Google, the company was putting heavy emphasis on code reuse. He believes that Google's codebase still suffers from results of that former policy in terms of compilation speed and maintainability"wikipedia
I had a delightful time in Texas, then back for a week of work (mostly fitting stuff to ships) and then off for a weeks vacation. My brain really needed a rest!
Saturday was a trip to Dallas with Jonny and much amusement was had starting off with a top-notch breakfast at Ellens Southern Kitchen highly recommended!
At the Gas Monkey Bar and Grill I ordered the vegetarian choice of Stuffed Peppers, only to find out they were stuff with pulled-pork!
Sunday I was the guest of the Smiths and had a grand time looking round the hill country and caves, my thanks for their time it was a good time!.
Coming from the UK I love big horizons and here we see the Kitty-Litter Castle in the hill country above Austin.
And then NIWeek stuff starts on Sunday night with drinks at the Ginger Man, great staff, beer and rubbish dartboards. It is here I discovered that great cider is made in Texas. Namely Austin Eastciders Original Dry Cider, after discovering this the week was a bit of a blur.
I'll admit this now, I deliberately limited myself, being an introvert I find crowds of people very trying, the good thing about Austin Convention Center is that it is so enormous you can always find some alone time. If I didn't get to the session I wanted to it was because I was lost, talking, in a meeting or resting my brain. Also we stayed in the Hilton, this was very handy for ducking out for a breather.
Monday was the Alliance Day and after the trauma of the keynote (I DON'T DO GROUP ACTIVITIES!!!!!!!!), it passed by nicely. Various kick-off drinks etc happened in the evening and people kept giving me name stickers to fill in, even approaching my fiftieth year I find it difficult to write my name sensibly on a label. So if you met a loud idiot with MEGATRON on his label, I'm afraid that was me. I got to sit on a table with Darren, Stephen and finally met Christina and think I enjoyed your company more than the other way round.
Tuesday was all business, lots of meetings and I think they went OK. Thanks to all for organizing them. Then I wandered down to the LAVA BBQ via the Mohawk (a bar I like very much, old punks seem welcome there).
Wednesday My presentations. Sadly TS9044 - Shock Test Using Multiple Synchronized Racks had stiff competition by Jeff Kodosky and Stephen Mercer in the room next door. Therefore there was plenty of spare seating in this one, there was a lot of NI people in attendance and that was perfect tho', they were actually my target audience (more on this in my next article).
In the afternoon came ISO 9000 and LabVIEW - TS9456 and this benefited from being a Jeff Kodosky Top Pick, I fact I was unaware of until after the affect. Honored!
An honor I shared with TS9446 - Project Templates: Making the Most of Code Reuse by Becky Linton, which I am waiting impatiently for on video.
This vindicates the somewhat uphill struggle I feel it is when talking process in the LabVIEW community versus talking technique. Another plus-point is that the interest in code reviews seems to be increasing, the session on this was extremely well subscribed.
Anyhow here's my presentation.
Q1 32:43 - Dmitry - Is it all internally driven or do you integrate customer processes too
Q2a 34:07 - Fab - As a relaxed person how do you make everyone agree on a processes and then stick to them.
Q2b 35:10 - Fab - When you get audited you can feel that you have to have very time consuming processes, this appears to be more minimal
Q2c 35:45 - Fab - Is it true that we sailed through our accreditation with nothing but a well done chaps. Thanks Fab
Q3 36:08 - Does this process apply to everything, internal and external.
Q4 37:48 - Did the ISO9000 accreditation change your process or did you get something value added by doing this work.
Q5 41:20 - How many times are you audited?
Q6 42:55 - Merging - how does your process handle merging.
Q7 44:10 - Michael (I Think)- Can you elaborate on the sub-contract model
Hope it is of use. I've had some nice feedback on it. I'm going to list the questions as soon as I get a free moment.
The best thing about presenting at NIWeek is the quality of attendee. I had attendees from USAF, Boeing, Lockheed Martin, a lot of military research, SpaceX, research from various countries. As a platform for putting yourself in-front of quality companies it's second to none.
I missed a lot of the other sessions because I was either nervous about presenting or really relieved at having presented. Although I did go to TS9723 - DQMH: Decisions Behind the Design and witnessed some ugly trolling behavior from people/person who were not there to learn, but to criticize. My response would have been very much less professional than the presenters, something along the lines of "Fxxx Off and get a life". If you don't want to use it, don't use it. Sorry it's the first time I've run directly into this type of behaviour and I feel protective of people who share code and ideas.
Thursday Seriously relaxed now, so I went to see TS9725 - Understanding Test System Performance and in the evening went to Pete's Duelling Piano Bar with a group led by the wonderful Jeremy Marquis who's where's Where is Jeremy now? twitter feed thoughtfully ensures you need never be alone at NIWeek. His lovely wife Rozann also ensures that not idea is never left unlistened to. I love live music and thought I might hate the experience of Duelling pianos, but it was amazing! At midnight I found myself sat in a leather armchair listening to Industrial dance music and drinking tequila. Austin is fun!
Friday flight home. Club World is very nice, thanks for the upgrade!
Now I just need a Return on Investment to justify more trips ($6000 to get back)
swatts
on:
A Lil bit of History ..
Petru_Tarabuta
on:
Some Boring Statements
Craig_Petersen
on:
LabVIEW and Linux Review
Taggart
Dhakkan
on:
LabVIEW OpenSUSE Leap15.5 on a LattePanda V1
