Confusion or Enlightenment [Update]

Confusion or Enlightenment [Update]

Editor’s Note: Gunnar responded on his blog.

A funny thing happened at Mil-OSS LANT, I disagreed with Gunnar Hellekson!

Let me be clear.  Gunnar and I see eye to eye, so I feel the need to work it out in print.

As usual, Gunnar put forth a very cogent and highly articulate presentation about removing complexity from software design using better design choices, fixing specialization in IT to something saner, oh and open source software.  As referenced on page 18 of the presentation, “Craftsmanship is the enemy”: shout it from the rooftops. Stop building better engines and start building cars, so consumers can consume not construct.  If welders can weld anything, why can’t system admins admin any system?

Read the presentation then come back.  Note: You can still get his argument without hearing him (though if someone did happen to video the presentation, be kind and put it online).

No, really, I’ll wait.

If you still aren’t sure, read this article about a recent keynote from Jim Whitehurst. It features a similar message, commoditization of the whole IT stack.  The real Information Revolution following the patterns of the Industrial Revolution: standard, disposable, interchangeable parts.

So far, so good.  I agree that this is where we need to be and that we aren’t quite there yet.  “Embrace and extend” still muddies the waters of standards; vendors create ‘value’ with special sauce APIs that do nothing other than obfuscate access.  Cloud is gaining momentum, offering to hide much of the cool complexity that we engineers have built; which is a Good Idea™ because much of what I do needs not to be seen by the general public.

The value of the example car is not quality of the individual components.  You may think about overall quality but at a higher brand level, not a component source level.  You may also assume that certain brands will source higher quality parts, when in reality that may not be true.  The true basis of car value is neat options, eye-catching style, loyalty capturing brands, and price bands that support fair(ish) comparisons.  The overall experience doesn’t substantively change:  steering wheels steer, engines move the wheels, blinkers blink, wipers wipe, and ultimately you get where you need to go.

Custom Tree Houses For All

My disagreement came during the audience participation section, which really isn’t being specific with a Gunnar presentation since there’s typically lots of audience participation.

Dan Risacher asked a question that seemed innocent enough as a clarification: if we are talking in terms of tree houses, where is the commoditization point?  Are the bolts and boards the commodity or is it the whole tree house?

And as I started nodding, expecting to hear “interchangeable component parts”, Gunnar said, the whole tree house.  You would buy the same tree house as everyone else and modifications would be something you could have done to it later.  No bespoke tree house building allowed.  (I’m paraphrasing, Dan or Gunnar please feel free to correct me) That’s where the nod turned south, or west perhaps.

Maybe it’s just scar tissue making me inflexible – earned trying to convince the unique snowflakes of previous customers that their precious workflows weren’t all that unique – but that seems like a step back in time and toward the, dare I say, proprietary.  ”Any color, so long as it’s black” is not the Henry Ford echo I want to hear.  It seems to fly in the face of OSS engagement as well.  If “$THISAPP” doesn’t do want you need, create the functionality and submit a patch or module.  Extensible frameworks, modular designs, powerful abstractions have been the watch words for development. And we know best what it is we need to do, right?  So standardize the interfaces between components and let people compete on the widget sets.

But that’s where we are right now or at least in the neighborhood of, and it isn’t working so well.  We’ve invented a new way of developing software to compensate for the mindset that development will always be late, wrong and aimed at targets that have moved since we started.  Can you imagine Agile applied to industrial design?  We would be a skinnier nation based on around walkable urban areas dreaming of the day when we could use these newfangled auto-mobilizers and machines that washed clothes and dishes.

The Path to Enlightenment

Perhaps Ford was right about software too – stop designing faster horses and build software for the great multitude.  Design software to serve a function that has some customization points; change the wheels, change the paint, but not the way you steer.  But how do we get around the fact that we are essentially implementing business processes in electronic form and that business processes vary?  That’s where my twitch starts up, the fog descends over my eyes, and I look for a hole to hide in.

Is there really value in our business processes?  As a business, our tools are only valuable because they let us exploit our data.  Without data, our tools are useless and, conversely, without tools, our data is useless.  If we all have the same tools, then aren’t we going to exploit data in the same way?  How do we discover new ways to slice and dice our data in interesting and valuable ways if we don’t have bespoke tools?  Can a CRM be a differentiation point for a sales company? is betting on no.

Maybe the answer lies in changing our point of view: radical adoption of open source ideals across the business.  If everyone has access to constantly improving and peer reviewed processes, then everyone benefits from those improvements.  Local changes can be maintained internally or shared back to community as a fork.  Interchangeable business processes can allow us to spend less time how we do things and more time on why, putting the focus on culture and not procedure.  “Lean” business is about reducing non-value-adding work (muda), overburdened systems (muri) and uneven flow (mura). “Six Sigma” is about decreasing defects by minimizing variability.  These design patterns are adapted from manufacturing and adopted by businesses around the world.  Standardized, openly published, constantly developed process patterns that have been re-contextualized is open source.  All of us are smarter than some of us.

The path to enlightenment often starts with a disagreement.  Am I getting closer?  Gunnar?

Editor’s Note: Gunnar responded on his blog.

Images Courtesy of Mil-OSS and Brandon Sheley

Matt Micene is a Solutions Architect and lead engineer for DLT Solutions. He has over 10 years of experience in information technology, ranging from Solaris and Linux architecture and system design to data center design to long, coffee filled nights of system maintenance for various web-based service companies. In his current role, Matt advises customers in the pre-implementation stage, with the adoption and understanding of technologies, such as cloud computing and virtualization. He assists public sector customers with selecting the best building blocks to create environments supporting their missions. A strong advocate for open source, Matt is also a Red Hat Certified Architect (RHCA) and was named RHCE of the Year in 2010.