Ideas

[swatts]

Hello my LabVIEW Lovelies

This is a topic that has been floating around my head for too long now and I've been mulling it over to the point it has become a bit ironic.

I'll warn you now, there's no LabVIEW here, but there is one of the things that cause projects to go horribly wrong.

I have lots of ideas, here's one of my less stupid ones.....

Business Card Top Trumps

So rather than a boring old business card, you get to make your Top Trump business cards, where you pick your cliched business attribute from a set number (110% Max from a bucket of 300%, only I'm allowed 110% for everything as it's my idea!). And you don't just give them away, you have to win the card fair and square!

What a brilliant idea you may think and you'd be right, trouble is ideas are cheap and rightly so, they should be cheap! An expensive idea is a very bad thing. It's converting the idea to reality that is the expensive thing, it's expensive in time, energy, effort. It's the blood sweat and tears that makes an idea expensive.

So why is an expensive idea such a bad thing? it's because it makes it harder to give up on. Think evolution..lot's of ideas, throwing away the ones that don't work.

Let's apply this to the software design process. We spend ages writing a "complete" list of all requirements, we design our code to cope with future requirements, present it to our customer and they start picking it apart. We feel defensive having worked really hard on this, it is the pinnacle of our programming capability,  we have also added complexity to cope with imagined future requirements. Our ideas are expensive and the term I use here is design pride.

Writing a "complete" list of requirements is a proportionally similar effort similar to writing code in a high level language. As we've discussed before the accuracy of requirements usually survive to point of the customer seeing the software (sometimes using the software). Reality has a habit of throwing up a whole new set of requirements.

So how do we keep our ideas cheap? We need to expend the minimum amount of effort prior to presenting a design to the customer.

This also applies to other areas of life, good management encourages lots of ideas and assigns no blame to the ones that don't work out. Experimentation is good and should be done with the minimum of cost, if you invest $$$$$$ in a feasibility study it is unlikely that the project will prove to be unfeasible (so many death-march projects should and could have been killed early saving billions).

Cheap failure is fantastic way to learn.

Here's hoping you hit the G-spot (now that's what I should have called this blog!!)

Much better on the Randomness this time I think!

Much Love

Steve

[FabiolaDelaCueva]

Steve,

Great thought provoking article as always.

One of the things that I love about LabVIEW is that it gets you earlier and faster to the point of failure. 

This is important, because the sooner you find those failures, the sooner you can address them.

One thing though, one has to remember to build early and build often. If the executable is only built at the very end of the project, you might be in for a big surprise.

I believe that a requirements document will never be accurate or complete if the user has not had a chance to "play" with the product. Sometimes delivering exactly what the customer requested at the end might result in an application that is never used, because what they requested/wanted was not exactly what they needed. So, getting prototypes and early betas or even alphas to the customer is important in ensuring having an application that doesn't become a virtual paper weight.

Thanks,

Fab

[Ian_Billingsley]

Great point Steve, I totally agree.

Where the customer allows, I'm a big fan of sketching out software screen designs and then throwing them away just as quickly. By about the 6th or 7th iteration we are usually getting somewhere close to what we need. This works well as an initial stab at requirements definition too.

[Pie566942.0]

Thanks for another thought-provoking article, Steve.  Excellent point, Ian.  The UI prototype is one of my strongest requirement development tools.  In my mind, software development starts with the external interfaces: electrical, database, human, etc.  Both the customer and our developers do hand sketches.  I'm an ardent XControl user.  XControls can have the dual effect of putting basic/simulated capabilities behind a UI prototype and keeping the customer shielded from source code.  I've seen how spiraling a UI prototype with a customer can help establish correct expectations. -Steve K

[gobshite]

Don't call your blog "the G-spot", no-one will find your ramblings .......

[swatts]

I set em up and he knocks it out of the park!