Sunday, August 24, 2014

The Diagnostics Plug – a missing abstraction in most systems

Another car analogy – this time with iPhone-Support...

As the website tom's guide - tech for real life tells us

“... Every car sold in the U.S. since 1996 features a built-in engine control computer that can be accessed with the right tools. This is called On Board Diagnostics-II (OBD-II), ...”

And actually this information can be accesses all the time – even while the car is driving.

Nowadays it is actually pretty simple to access the diagnostics information from the car. All you've got to do is buy an odb-II bluetooth adapter and an application like DashCommand or Engine Link or the like and you easily can see all the information from the diagnostic sub-system of your car. Some application also allow for the extraction of the error codes and error log. If you use one of these applications you can find out what's really wrong with your car as soon as you notice that something is off – way before an appointment at the garage would be possible.

Having a running (software) system is much like having a running car - it gets harder to work on the parts when there is more load on the system. If the database load is at 80% it becomes hard to run an additional query to find out how many stale entries are in a certain table. And if the server is maxed out, it is not so easy to just run a second instance of the system just to find out if the supposedly optimized css really is optimized. Some systems (like Apples OS-X) have built in mechanics to enable the collections of diagnostic information with a relatively low penalty for the overall performance of the system. The same holds for some web-servers and database systems – but what about your business application? Is it possible to easily find out how many logical errors occurred in the last half hour? How many searches returned too many or too few results? If that isn't possible, you might not yet have had the necessity to start exploring these types of questions.

If you do have the information available it is quite often the key to effective (end probably also efficient) bugfixing and code optimization.

In his work Betrand Meyer introduces us to the concept of “design by contract” and the related concepts of pre- and postconditions as well as invariants. While Betrand Meyer originally thought of aborting the program whenever any of the expectaions (assertions) was not met, I found it a sensible approach – especially for “legacy” systems that have been running for a serious amount of time – not to stop the whole system, but only to make a “note” of the violation and make these notes available via the diagnostics port for everyone who is invested in the health of the system.

By analogy, I think it's a good idea to make the diagnostic information of you system (any system) available at runtime too.

Disclaimer: “Just” make sure that this diagnostics plug is not also providing access to internals that should not be available from the outside... like credit-card information ad the like.

Till next time
  Michael Mahlberg

Sunday, August 10, 2014

Bigger and smaller pieces in the flow - think "Heijunka"

One of the always recurring discussions when talking about flow-based software development processes is the question of the appropriate size of the work-items.

The lean production concept of "leveling" or "heijunka" addresses exactly this questions, but it is sometimes a bit hard to translate lean concepts from production into concepts that are suitable for knowledge workers.

The basic idea – as described nicely in this wikipedia article – is to make sure that the amount of large and small pieces in the systems "levels out" so that an even flow is possible for all sizes of work-items.

To instantiate such a process in knowledge work we are once again faced with one of our basic challenges – to create a balanced mix of small and big work-items we have to know their size beforehand. And usually we don't. But this basic conundrum still is manageable if we allow for some corrections further down the way.

Nonetheless the work-items have to be analyzed at least to a certain degree before they can be fitted into different "Size-Boxes" (if you're emulating some kind of heijunka box).

Once you do have the different sized work-items though it is possible to employ different methods to manage the flow or distribute the work between different swim-lanes.

So - do you have some approach to "heijunka" in place?

Till next time
  Michael Mahlberg