A poem on Innovation

This makes me smile...

I multiply your projects by words I can’t pronounce,
And weigh your published papers to the nearest half an ounce;
I add a year-end bonus for research that’s really pure,
(And if it’s also useful, your job will be secure).

I integrate your patent-rate upon a monthly basis;
Compute just what your place in the race to conquer space is;
Your scientific stature I assay upon some scales
Whose final calibration is the Company net-to-sales.

And thus I create numbers where there were none before;
I have lots of facts and figures – and formulae galore –
And these quantitative studies make the whole thing crystal clear.
Our research should cost exactly what we’ve budgeted this year.

Source: R. Landon, cited by Dr A. Bueche (Vice-President for Research and Development of the US General Electric Company) in ‘From laboratory to commercial application: some critical issues’. Paper presented at the 17th International Meeting of the Institute of Management Sciences, London, 2 July 1970.

Facebook Wiping out Banking?

The "idea" is interesting and definitely worth monitoring, in summary the ability for facebook to "enable" peer-to-peer lending which in turns allow for the folks in facebook to buy more nonsense to paste up their wall.

But think deeper, what if it's not all "nonsense"; what if it unleashes a whole new arena of "alternative lending" mechanism driven by rabid virtual consumerism within the Facebook ecosphere, wouldn't that jeopardizes traditional banking?

Busting the Mythical Man Month

How to quadruple your productivity with an army of student interns

Posted in Ksplice on March 10th, 2010 by Greg Price – 17 Comments

Startup companies are always hunting for ways to accomplish as much as possible with what they have available. Last December we realized that we had a growing queue of important engineering projects outside of our core technology that our team didn’t have the time to finish anytime soon. To make matters worse, we wanted the projects completed right away, in time for our planned product launch in early February.

So what did we do? The logical solution, of course. We quadrupled the size of our company’s engineering team for one month using paid student interns.

The Ksplice interns, ca. January 2010. Photo credit: http://archive.cternus.net

Now, if you happen to know Fred Brooks, please don’t tell him what we did. He managed the Windows Vista of the 1960s—IBM’s OS/360, a software project of unprecedented size, complexity, and lateness—and wrote up the resulting hard-earned lessons in The Mythical Man-Month, which everyone managing software projects should read. The big one is Brooks’s Law: “adding manpower to a late software project makes it later”. Oops.

Click here for the full post.

Enterprise Architecture - The Urbanization & Townplanning Analogy

It suddenly just hit me that Architecture is probably a misnomer. Technology vendors have been trying hard to model the discipline built into engineering that adoption of the name "architecture" would hopefully imbue the arts and science of technology with something more "tangible".

But here's the thing, (note: real architects may disagree) buildings are "built to last" while IT systems undergo constant evolution and sometimes even revolutions. Although the same physical constraints of space and loading applies, IT systems are far more advantaged as the underlying code can continuously be tuned and by scaling the hardware outwards; you could always increase the total system loading by further increments.

Hence more appropriately, Enterprise Architecture should adopt the Town Planning & Urbanization principles. Buildings stand by itself (well, other than tapping on the grid, water supply, transport system and waste disposal) while a single IT system may depend and provide data/information to various other systems.

A township requires various amenities in order to flourish, e.g. schools, religious centres, community hall, roads, car park, commercial and housing areas and each of these facilities are constantly remodeled. A vibrant township is one that is constantly growing where new buildings are added and old buildings either refurbished or demolished. And while all of these are happening the people are able to live and go about their daily routines with relative comfort. The same goes with IT systems; there's a great number of interdependence between one system and another, between human and machine; as well as culture and environmental forces - The same requirements for complementary benefits, apply.

The danger that I see with over emphasizing the word "Architecture" in EA are fascinations with framework, order, certainty and a result that is as unchanging as the great pyramids.

Unfortunately; that is exactly what you'll get, grandiose constructions driven by ego maniacal pharaohs that serve no other purpose than encasing a dried up dead body.

Microsoft Pivot

A BI Dashboard + Seadragon? Whaddaya think? I happen to think it's cool, and hopefully broadband of 100Mb and more would be ubiquitous enough for us to enjoy it sooner.

Failure Induced Change

I’ve started a few discussions on the concept – Built for Change, and although I've promised myself to be more positive, I can’t help but to share the following observations and comments.

When the organization is ruled by “Failure Induced Change”, the situation perpetuates like a bad case of dermatitis. For example, during a failure; catastrophic or otherwise the organization will be hard pressed for system up time. The solution will more than likely be a hack job/workaround versus a well designed and tested solution.

However, there’s just insufficient time, too much stress and too many customers to keep happy – excuses that deafens the voice of logic.

Hence we wait and pray that the duck tape and glue-ons last long enough until the actual solution comes in. Now comes the moment of truth; this is where THE BUSINESS should have no hesitation in putting in place the intended solution scheduled 3-4 weeks prior. The question is – Do you have the guts to go through with it?

Imagine that you have to make this decision when another highly sensitive production system now tethers at oblivion but IT comes to you and requests, “We seriously need some if not all of the parts in flight to solve this new disaster because the previous system is already “stabilized”.

What’s the solution to this?

With all sincerity – BITE THE BULLET! There’s really no two ways about it.
Without which the subsequent downtime ricochets like aftershocks of the recent Chilean quake creating just as much damage if not more than the first outage. The organization just cannot afford another hack job.

I am not purporting that the team takes its own sweet time designing and carving out reams of architectural documentation and philosophical debates between options 1 through 13. There’s really:-

1. Option A) - The best solution that’ll last 3 years at least (barring more sticky situations like an impending upgrade – usually politically motivated)
   
2. Option B) - The second best option; what are the business compromising on and can we afford these compromises.

Work around the clock if you have to, because the sleep time invested here will be well worth it. I like to end with a quote from Dean Smith, a consultant that I had the privilege to work with despite his hard ass approach to implementation ~ paraphrased.

“When I do build a system, I want to make sure that I am not phoned in the middle of my sleep for the next 3 years at least...”

p/s: The quote may sound contradictory, but I’ll explain next time. Cheers.