Rant on The Concept of Task Scheduler

<rant>
A few days ago; browsing Wikipedia; a small little detail caught my eye.  The .NET framework is finally getting a means to schedule tasks.  Task schedulers are nothing new (they have a fairly long history), the most prominent at the moment are Intel's Thread Building Blocks and Apple's Grand Central Dispatch + Operation Queues.

In general, the idea is very simple.

Threads + critical sections + error-prone humans writing code = race conditions + deadlocks + other "joys".

Ok.  That's not good!

The race conditions are never a good thing.  What we want is to get rid of race conditions (or eliminate their likelihood).  Race conditions arise from bad use of critical sections, such as two threads mutually blocked for each others' held resource.

Eg.  Thread A needs fish and thread B needs bread.  Thread B has the fish and won't relinquish until it has the bread.  Thread A has the bread and won't relinquish it until it has the fish.  Deadlock.

Eg.  Thread A should complete it's tasks first, but thread B manages to get started ahead of time due to a programming mistake.  Race Condition.

For deadlocks, we just need ensure that a task only starts when it has all it's resources available, and when it ends it doesn't keep a hold on any resources.

For race conditions.  We do the same; make sure that the order is properly specified.  Rather than specify a list of things to do with convoluted gates keeping everything running in order; we tell the underlying system what the order is as a tree of dependencies.

Grand Central (from my quick reading) helps with the former and a bit with the latter (it uses semaphores).  Operation Queues and Intel Thread Building Blocks focus on the latter (I'm more familiar with this model of operations).

I'd go into details of the specific APIs; but that can be found all over the web - and more coherent than I'd ever manage to write it.  And the APIs are moving targets, the concepts not so much.
</rant>

Rating Software Goods

<rant>
Normally, when rating a piece of software, I think numbers.  How many features?  How fast?  Kitchen sink?  It's starting to dawn on me that this thinking is what leads to abominations that Visual Basic is so well known for - forms with countless features.  Quickly wired up - frais-du-jour!

So my thinking is starting to shift towards: how can we quantify the usability of a user interface?  Looking at the runaway success of the iPhone's UI - there must have a way to assign a metric?

In the physical world, we'd call it the quality of the product.  Something made of cheap parts is expected to die sooner than something made of quality parts designed to last.  It's common sense - in a sense.

How do we build a UI?  Maybe the construction will lead to the quality questions.  Hmm, Windows Forms, drag a few text boxes, connect it to an Access database - and voila - instant abomination!

Wait, a quality UI....  That requires thought.

Recently, my thinking is that a good UI is like a good book.  A good book does not need a manual to read - in and of itself consists of the manual.  Some books are technical in nature demanding a certain background - just like certain software demands more knowledge of their users.

A good book does not confuse the reader by overloading them with information.  Neither does a good UI.

A good book will have information that is easily accessed.  So does a good UI.

A good book will have a consistent writing style.  So will a UI be consistent.

A good book requires a lot of forethought and consideration as to how all the chapters will flow.  A good UI, I'd argue, requires just as much thought.  Blindly throwing text boxes is the equivalent of a rough draft of a book where ideas are present without any links or structure.

For example, a good book will usually try to use a person's intuition into a given matter before burdening the person with the technical aspects.  Therefore, once the technical aspects are presented, the reader just needs to learn terminology as the concept already makes sense.  UIs generally miss the boat in this regard.  And that's a challenge to resolve...

Note:  I'm aware of the click count as a metric in web pages.  But I'm inclined to say that UI design trumps click count.  And good UIs don't require that much effort on the user (the comment is circular on purpose).
</rant>

Rant on Rapid Prototyping of Software

<rant>

I tend to vote for throwaway prototypes.  Something whose initial purpose is to test something, whose design doesn't really matter.  Where the prototype is not intended to become the final product.  My reasoning is that organized code actually distracts from getting the goal done.

Why?  because a prototype is supposed to answer some form of feasibility question.  If the prototype is designed to become the entire system, then something's wrong.  It could, in retrospect, become the final product - but this shouldn't be planned.

Why again?  agility.  If you're testing the stability of  the algorithm of a physical system, do you need to run it in the final application?  Most likely no - you know the performance characteristics of the algorithm and any computational limits that are imposed.  The goal is to write, as quickly as possible, an application to display the results and to set up the system with harsher conditions than what is expected in the final application.

Expanding on this idea - if the code is expected to be used as-is - maybe the programmer might spend extra time organizing the code, making it legible, documenting.  Actually, a prototype just needs code and a person that understands it.  Organization is over-rated - whatever gets the code written the fastest is most important (why use accessor functions when variables can be directly accessed?  why comment if the algorithm will be quickly swapped out?  why worry about aesthetics of the visualization when the goal is to observe stable and correct behaviour?

Again - let's consider a user-interface.  A very touchy subject, as reading a user's mind and knowing what's best for them is actually harder than it seems.  A good user interface does not need a manual as it is intuitive  (that's a comment on the current state of UIs though - if training on a UI is needed - something's wrong in my opinion).  I believe it more to be a hit or miss situation - UI will either be good or bad.  It's like throwing plenty of things at a wall and seeing what sticks.  Now - if we create a prototype designed to evolve into the final product, then there is a layer of organization which implies assumptions.  There is structure.  There is documentation.  Comments.  Plenty of work that has the real potential of actually being trashed rather than seeing the light of day.  It should be done as fast as possible just to ensure that users can test.  It doesn't even need real data - just a realistic progression so that users can judge of the ease of use.

What could change in a UI?  Buttons need to shift around.  Sub-windows?  Lists?  Custom controls?  Special effects?  Each of these could be added and removed at will.  A good UI should have several test versions.

Then - what happens when a prototype has discovered the path to follow?  We pillage what's salvageable and good, as quickly as possible.  We document.  We comment.  We organize.  And tackle the next challenge.

Isn't a small amount of spaghetti code to prove a concept worth it if concepts get validated or disproved quickly as opposed to developing a large framework?

As in quickly - a prototype should not take more than 4 hours.  It should be focused.  If the prototype includes building a functional version of everything - then maybe you aren't building a prototype...

</rant>