Random Ramblings on LabVIEW Design

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

Design is not black and white!

swatts
Active Participant

“Examinations of typical programming projects will show that, over the duration of the project, programmers spend over 50% of their working hours looking for and correcting their mistakes. The usual 'solution' for this is remarkable.....

We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process”

Glenford J Myers 1978

I've had the good fortune to look at  lots of software in a variety of languages in my career and it is endlessly fascinating, and when I talk about design to some perpetrators of bad code a common response is that oh! design is not black and white, there is a grey area. This got me thinking.....

Design.PNG

In quite an angry moment I drew up this representation of what I have experienced, I think design is various shades of brown, a small grey area and an even smaller white area. The brown area is various shades of awful.

The time graph can also be viewed as a cost graph and it is the cost throughout the lifecycle of the application. Disclaimer:This is based on my experience and not research.

So looking at a brown project.......

It's a classic code and fix job, tight coupling makes the code brittle, inflexible and hard to change. Lack of cohesive modules and poor abstraction makes the code hard to understand. So 95% of the project time is used up and 95% of the code is written. The last 5% of code will not take 5% sadly, you'll be adding functionality to code that will be resisting you. Bugs are hard and expensive to find, tight coupling means changes made will ripple outwards causing unpredictable results in related modules. Simply put, it takes a lot of time, effort and cost.

Compare with a grey project.......

It's had a bit of modular design applied to it, this design work gives the architecture flexibility. Changes can be made simply and easily at the end, when most customer input is usually given. The design work makes the code easy to understand, therefore bugs are easier to detect. Loose coupling ensures that changes and additions to a particular module does affect other modules.

But what about Exceptional?

One of the challenges for a designer is knowing when to stop.

So are you a designer or a syntax jockey?

A designer will be spending their time thinking about the problem that they need to solve, a syntax jockey is likely to be thinking about what new tool or technique they can apply.

Software Facts of Life

As grown-ups I think we can face the truth.

  • Software is complex
  • Software is not malleable
  • Software will have bugs
  • Software will not be fully defined until delivered

Badly designed software exacerbates these problems.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments