Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Re: LabVIEW Life Lessons #10 - Quality vs Deadlines

Active Participant

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!

Lots of Love

Steve

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Comments
Member

For me personally it gets easier and easier over the years to stand my ground when telling customers 1. that we will miss deadlines and 2. when explaining the reasons. With more experience comes more confidence in oneself, and with more projects comes more trust from the customer.

What I had to learn was that sometimes it's eventually better for the customer if I "disappoint" him by not meeting the deadline, 'cause in the end the result will be way better. I can't remember any delayed project that didn't turn out well eventually.

Long story short: Once more spot on, Steve!

Joerg Hampel, CLA
Active Participant

One thing I always ask now is "why". Why does it need to be finished by this date?, if it's a hard stop I then ask what is the minimum required to satisfy the hard stop criteria. Quite often they just need to do a set of tests, test some hardware, offer a milestone to their customer. These can often be done with a sub-set or mixture of manual operations.

If it's only to get a payment because of end of year, you can put the money in an escrow account.

As I've said before the customer required delivery date is separate from the engineering activity. The real delivery date is more to do with the engineering effort, completeness of requirements, relationship with the customer, capability of the hardware, risks than it is with the financial year.

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Active Participant

A corollary to "why" is "how much".  It's hard to add people to a project in flight, so if you can't slip the schedule, then you might be able to defer features.  Better to deliver high-quality code with some features than low-quality code that claims to have all the features (but really delivers none, because the code doesn't work).

Active Participant

100% agree

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Trusted Enthusiast

I wholeheartily agree with the sentiments in this blog post.

 

I sometimes have the feeling that I'm stretching my employers patience when implementing something just so that I can do it right.  If so often gets pigeonholed as the developers "expressing themselves" with negative connotations.  Finding yourself in the position having to continually justify writing better code can be exhausting and often means working "on the edge" regarding what you're told to do and what you actually do.  Nobody ever notices the changes you can make to refactored software afterwards because they are fast and people then assume the changes were simple.  Truth of the matter is that developing scaleable maintainable software in a hostile environmant is incredibly unrewarding because the time savings for future modifications goes completely unnoticed whereas the bit of time taken to get to that position can cause no end of grief.

 

I maintain to this day that the only way I can write good software is to accept and embrace that at any point in time that I can get fired for not doing exactly what was asked of me.  Getting fired for writing better code is one of the best things that can happen.  Removing the fear of losing one's job (or customers depending on your employment status) really clears the mind as to finding the optimal solution to any development problem.  YMMV.

Active Participant

yup, I feel your pain! I guess the reward is to not have too many skeletons in your cupboard.

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png