Thinking about Design Thinking

[swatts]

Hello Lovelies,

A couple of notices.

First, I've had a couple of presentations approved for NIWeek 2019 and they compliment each other, one is a reprise of my Immediacy presentation and the other is on Lean LabVIEW. I'm quite pleased with both of them and they will have new info in them (I've given the Lean LabVIEW one at a Developer Days and the Immediacy one at a European CLA summit). Hopefully you'll come say hello.

Second I had a spiffing time in Krakow with Prof Maj and all my CLA pals and some new NI Product Manager friends. It was great fun and Krakow was amusing and beautiful.

I've rescued a few jobs over the years and my #1 interest is what is going through the designers mind. Ploughing through another rescue job I had a small epiphany regarding design approaches and the differences in design approach.

Apparently there are 2 types of design Top-Down or Bottom-Up.

Top-Down

If you remember structured design you would define your system downward, gradually adding more and more detail.

Bottom-Up

Whereas bottom-up is the reverse.

As you can infer from my flippant explanation I don’t really buy into it, but I do think some practices push programmers into designing in a bottom-up fashion. If you give an inexperienced programmer a list of requirements, you may find that they write a bit of code to fulfil requirement#1, another to fulfil requirement#2 etc etc.

Ticking off requirements is a bottom-up approach, whereas top-down view would dictate architecture to fit the requirements.

I've observed that thinking about Top-down or bottom-up is just plain wrong. You need to think about areas of risk, areas of certainty and areas you want to delegate responsibility. This should then drive your design decisions.

Areas of Certainty

Most pieces of code need some common functionality.. For us it's

• Configuration
• GUI Handling
• State Machine
• Error Handling
• Exiting

These need to be easily modified.

This is where a framework would be handy and this can guide your top-down design.

Next you will have areas of certainty. As an example you will likely have some hardware specified. These can be defined, written and tested without more than a cursory glance at the customer requirements.

Examples are..

• PSU
• DAQ
• Scopes
• Reporting
• Storage of Settings and Results
• etc etc etc

Here you just need to offer a reasonable level of functionality, make it flexible enough and you may even have a re-usable component for your efforts.

This is bottom-up design.

Areas you want to delegate responsibility

Write an application for 4 scientists to use and they will give 4 completely different ways to solve the problem. This is when you need to design a system that pushes the decisions back onto them. This is where configurable systems are your friend.

Finally you will be thinking about UI design, State Machine design and every remaining bit of customer domain code. This will be a mixture of top-down and bottom-up. Abstractions will be Top-down.

So in this small example we've used such a mish-mash of top-down and bottom-up the only conclusion can be that these definitions are incorrect and probably unhelpful.

I believe the word "OR" in design is usually and indication that people don't fully understand the options.

So rather than thinking Actor OR OOP OR Functional, think Actor, OOP and Function where appropriate

It's not Events OR Queues, it's Events and Queues where you get advantages from each.

It's not Waterfall or Agile, use agile when the project requires it, use a stricter deliverable method for some of the internal system design work (i.e. stuff the customer doesn't care about).

Lots of Love