Test-Driven Development and GAMP

In the world of software development, there's a development methodology called, "Test-Driven Development" aka ("TDD") where you basically write the test BEFORE you write the actual functional code.  There are other tenants of TDD, but the notion that you write the test first is the main focus here.

By writing the test first, it forces you to look to see where your "goal posts" are.
 
I actually have no opinion on TDD other than to point out that it exists, and there are some principles with strong parallels in the FDA-regulated markets with respect to computer system validation.

The V-Model refers to the way in which (software) systems are validated and verified:

The only reason (I can think of) for why this is called a "V-model" is because someone is being clever with the Verification and Validation.  But I digress.

The point of the V-model is that someone actually went through and documented what the users/stakeholders wanted.  Then, they went through and figured out what functions match with those user/stakeholder desires.  THEN, they went through and figured out how to make those functions happen:

• User Requirement Specification (URS)
• Functional Specification (FS)
• Detailed Design Specification (DDS)

That's the downstroke of the V.

The upstroke is the part where you go about proving that what you designed actually made it into the actual system.  And the functions you said are available are actually available:

So in the world of computerized system validation (CSV, not comma-separated variable), the Installation Qualification (IQ) is what verifies that the items of the detailed design got into the system.  So the battery of tests that prove the correct software configuration was inputted.  

Operational Qualification (OQ) is the battery of tests that prove that the functions specified perform as specified.  For example, if your functional specification says that your impeller speed has to operate between 60 to 255 rpm, you should have a test in your OQ that runs the impeller at the boundary and within that operating range.

• Installation Qualification
• Operational Qualification

So what does any of this have to do with test-driven design?  Well, anyone who has validated a computer system knows that for the most part, the V is executed exactly as it's drawn: first the downstroke, then the upstroke:

You first write the URS, then the FS, then the DDS.  After this planning phase is over, there's the testing phase during which time you draft the IQ, OQ (and sometimes PQ).  And by the time you get to executing these tests, you may find nonsensical tests or deviations.  

And the reasons may be that you ran into these issues is because you didn't start with the tests (IQ/OQ) first.  

The TDD methodology is saying that you start with the URS (what the stakeholders/users want).  Then you skip ahead and write what a passing test looks like (IQ and OQ).  Then you go backwards and fill out the specification and perform the build.

The thinking seems backwards on first-pass, but it isn't without merit.

Tes(u)la Model X Ownership - Day 1

Today was the day I picked up my Tesla Model X from the showroom.  The showroom spartan as they were clearing out inventory for end-of-Q3.

Paperwork was pretty slender since all the preparation happened up front, and I got in and out in about an hour.

Initial Impression

The new car smell is very strong with this car.  Some people love it; I dislike it.  Very dizzying.

What's also dizzying is the regenerative braking which comes with in 2 flavors: Standard vs Low.   Coming from an automatic car, LOW is what you're going to be most used to, but since you're not capturing as much juice, this overall decreases the range of the EV.  Standard takes a bit of getting used to.  My test-drive was much the same.  Standard basically means that the moment you let off the accelerator pedal, you're not coasting... you're actually braking.  So if you're used to coasting in either a regular car or in a hybrid vehicle, this is going to noticeably jolt you forward everytime you abruptly let off the gas.

Between the new car smell and the STANDARD regenerative braking, it was a woozy day.

Key Fob

The Key Fob seems over-designed.  It looks like a palm-sized plastic version of your car missing what designers call, "Affordance"... obvious things to press.  Key fob looks like some sort of voodoo doll for the car.  You press the front and the front-trunk opens up.  You press the back and the rear hatchback doors open up.  You press the windows and the Falcon-Wing doors open.  Oddly, you press the hood of the car and it locks the car.  Haven't tried stabbing it with a needle to see if the car screeches in pain.

And while there are power-doors on the driver and navigator doors, there's no way to open those doors using the key fob.

Affordance

An affordance is the possibility of an action on an object or environment. Additional meanings have developed, largely a result of misinterpretations. The original definition in psychology includes all actions that are physically possible.

So the convention with all doors (since the beginning of cars) is that you pull on it to open.  You push it to shut.  The Model X has this crazy thing where you push on this bar to open the door.

There are 2 User Experience principles being violated here (as I understand it from Joe Natoli at Give Good UX):

Tesla has gone against convention.  Now, being conventional isn't all that great.  But convention is hard for users to break, so if you're going to go against convention, you ought to have a really good reason to do it.

Tesla has also gone against the user experience principle of affordance.  The possibility of action is an open door that comes towards you if you're on the outside of the car.  Pushing is the action going towards in the inside of the car.

For now, I'm going to trust that this is only a cursory violation of good user experience principles and that there are good reasons for it.