Always happy to jump on a bandwagon here's my review of the year....Random Style..
Best Day at Work....
So many to choose from, it's been an interesting year.
Flying to Amsterdam to fault-find Canbus on a flight simulator (didn't get a flight tho'!) or finding a great bar in Rome and being fed lots of locally brewed beer or getting ISO9001 certificate.
Thing that made me laugh.......
Challenge the Champions at NIDays UK (I might have been a little drunk, although not the drunkest!), my contribution was to re-arrange the bottles on the table.
Me, James Powell, Chris Roebuck, Adrian Brixton and Jon Conway all looking relaxed and happy, I like this photo.
Thing that made me cry......
Such a good dog!
Best NI Toy
Really loving the cRIOs with RT-Linux (we're using the 9035), such a big improvement on an already good product.
Best Non-NI Toy
IOSafe 214, waterproof and fireproof NAS. Expensive but really nice!
Decided to go the micro-services route for post-processing of acquired data, that way I'm not locked into LabVIEW if customers have Matlab or other ways of doing it. The post-processor is then called by a command line and the TDMS file fed as an input.
Oh and it has a funky progress bar.
Blog of the Year
For consistently good technical content it has to be ....
This year has been great for presentations, the presentations are more clinical and have a wide variety of subjects. Personally I love the show and tells and the project management ones......
All of them!, anyone who has the nads to stand up deserves this prize.
Proud Moment of the Year
CSLUG won best advanced user group and had >50% of the European CLA Summit presentations.
Best Comment of the Year
The entire thread on the Singleton article. I think it became that rare thing where we were all learning off each other.
Happy Christmas Christians and Happy Holidays non-Christians
I've done enough language stuff for the time being, it's time to look a bit closer at a subject that is far more interesting to me.
LabVIEW projects are getting bigger and more complex, generally SSDC is now working on distributed systems, large database enterprise systems or control systems. NI is wanting to sell system level hardware rather than single boards. All this means project failure can now impact on peoples jobs and company profitability.
I have referenced the Standish CHAOS study in presentations before and a quick look at the graphs will tell us that any improvement observed from 1994 to 2010 is marginal, statistically I would say that any improvement is within the general variance.
This is interesting because I am constantly inundated with propaganda promising me a brave new world of software development.
The take-outs from this are LabVIEW projects are getting more complex, and I would expect these complex projects to begin to follow the findings of the Standish CHAOS study.
If we now look at these two videos by Steve McConnell (If you don't know who he is then look him up!)
This webinar looks at case studies of 4 projects ranging from embarrassing failure to great success and the 4 judgement points are a nice simple way of evaluating a projects chances of success.
If you've not bothered to watch the video the 4 factors are Size, Uncertainty,Defects, Human Factors and how you manage each of them affects project success.
This next video is in a similar vein but looks at some common graphs associated with the software development process.
40 minutes in StevieMac (as he loves to be called) discusses human variations and it is a stunning bit of study.
Again if you couldn't be arsed to watch the vid, the spoiler is that human variations affect a project by factors way greater than methods or processes. So as an example filling your Agile team with idiots is likely to lead to failure.
1. Complexity
Sometimes a project is JUST DIFFICULT! The likelihood of failure is greatly increased as you add function points to a project. If you have trouble defining a project or you just can't picture the design in your head I reckon it's a sure sign you have to put some hard miles in up-front.
2. Bad Judgement
As was shown in the 2nd video sometimes a project will fail just by intelligent people doing stupid things, in the case of the various medical failures it was bad business as much as bad software engineering. It's well worth understanding the financials of a project before you begin.
3. Lazy Estimation
If you are fairly professional you will have some very busy times (being professional is a really attractive sales technique). It can be very tempting at those times to take a bit of a punt on the estimate and often you will be caught out in spectacular fashion
The general rule in our business is that we very rarely make what we expect to make on a project. I would hazard a guess that we're not alone on this. What is the percentage? well taking the CHAOS report terminology I would say the the majority of our projects could be classed as challenged, very few fail (I think we've had one canceled and this was essentially political). How were they challenged? The majority would be late for a variety of reasons, generally it's over optimism! Very few would lose functionality. This is all indicative of poor or lazy estimation. For us it is mitigated by sticking rigidly to fixed price, absolute openness and early release of useful code.
4. Lack of Experience
I touched on this subject in Damn! My Silver Bullet Appears To Be Made of Crap. The graph showing how experienced teams have vastly improved productivity over inexperienced teams in the second video backs up my feelings here. That doesn't mean that a team should only contain gnarly old gits (SSDC defined), but often employers are less than discriminating when employing LabVIEW programmers. That poor decision is often the foundation of a failed project.
Experience gives you the flexibility and resilience to change that most projects need.
NOTE: Qualification <> Experience
5. Lack of User Interaction
One of the most best bits of the Agile Manifesto is this
"Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software."
We need to understand that the industries that most benefited from Agile processes were not actually delivering software to customers at all. The simple expedient of showing the customer stuff on a regular basis was deemed to be a huge breakthrough!
If you are not doing this with LabVIEW you really are in the wrong game!
6. Inappropriate Cost Saving
I discussed this in The Cost of Failure Article. The only addition could be applied to the people doing the work too, in any engineering discipline paying peanuts really does mean employing monkeys.
7. Politics
You could be happily working away on your project and management change everything. We've also had projects that were designed for a nefarious purpose (in our case to extract processes from the shop floor so the factory could be closed and shipped abroad).
8. Dishonesty
Saying all is going well when it isn't is dishonest, similarly agreeing to unattainable delivery dates to win a job. Customers generally have fairly simple requirements with regards to projects, they expect you deliver what you you say you're going to deliver, when you said it would be done. Getting money for a project is usually a one-shot thing, going back for more money is incredibly difficult for all involved and is bad for customer relationships.
9. Offloading Responsibility
Quite often we find the customer expectation to be that not only do we design the software, we are expected to generate the requirements, specify the equipment and we have even been asked to redesign the customer hardware. In this type of job you need to be very sure of your ground because you are going to be taking all the blame.
The healthy situation is that the customer has the domain expertise and can communicate these as part of their requirements and feedback. Jobs are far less risky in this environment.
I've added Pascals comment into the main text as I think it more eloquently describes one of the points I am trying to make.
PascalHeinen wrote:
I also see this phenomenon in projects and I think that if we generate the requirements the costumer is less involved/impressed/excited about the work that is done. Because of him not having to think requirements through, he will change requirements if problems arise, just to move on with the project. Which leaves a bad tasted in my mouth.
10. Too Much Belief in Silver Bullets
This is a bit like self-help books that try to convince you that you're the most important person in the world and sheer force of positive thinking will make everything OK. It won't and probably the worst thing you can do to a complex project is add new processes or tools to it.
11. Inappropriate Design
If it doesn't fit the problem it's probably inappropriate. A large proportion of the jobs we rescue have had an unsupportable or just strange architectures applied to them. Similarly if the solution is radically more complex than the problem it is a sure sign of poor architectural decision making.
12. Trying New Things
An important, risky and time constrained project is probably not the best time to try out that new process or architecture. Essentially self-learning shouldn't be done on a customers paycheck (unless declared) and it also increases risk. A better way is to allow enough resource to attempt new stuff on internal projects or discuss it with your customer, sometimes they are willing to take the risk if there is a tangible benefit.
One reason I like fixed price work is that it forces you to analyse risk well and to then push these risks to the front.
I'll leave with a motivational poster to set you up for the new year.
Jacobson
on:
AI is going to take our jobs - everyone should panic now.
swatts
on:
LabVIEW Firmata - Easy control of Arduino Microcontrollers
Dhakkan
on:
LabVIEW OpenSUSE Leap15.5 on a LattePanda V1
LFBaute
on:
Sneaky Peak and Some Love to Spread (CTI)
jenniferbni
on:
1 Million!
Enrique.Noe
Taggart
