Jeff Jonas

Rapid Application Development: Fast Car No Map and 50 Laps to a “Who House”

[If you have never been involved in a custom software engagement (i.e., on the software builder side, customer buyer side, contract lawyers, etc.), there is no need to read this post.]

Rapid application development and prototyping have their place. One of these places is not the creation of complex, mission critical, ultra-high performance systems (i.e., space shuttles not mash-ups) – where it is essential that in hindsight the system appears well thought out, explainable, maintainable, etc. The simplest post-project assessment being, “Knowing what I know now, I would have built it exactly this way!”

The only method I am aware of that has a reasonable chance of making the above claim involves building a system based on stable, pre-defined, well-conceived blueprints. When operating off tight specifications, what you end up creating is virtually no different that what you were envisioning at the start … including the very first brick laid.

If you start building something without a precise road map, every time you have a design revelation, resource conservation drives one to make compromises. It is in this way that the air conditioning unit ends up on the roof of the car, the stereo mounted to the back of the driver’s seat, and so on. What rapid application development environments can lead to is the fast, iterative (50 laps) construction of a  Dr. Suess "Who House" or a Rube Goldberg-like contraption.

My primary issue with rapid prototyping, rapid application development, iterative development, and the like is the creation of valuable artifacts that one is hesitant to later discard at a whim. On this path, it becomes more prudent to perform a least-effort modification of A to become B. This compromise is compelled by the urge to preserve earlier investment … even if the best tact involves utterly discarding A and constructing B from the ground up.

It is therefore my belief that the most valuable prototyping tools, rapid application development environments, etc. are those that leave the designer with a sense of “as close to zero investment.” Radical changes to the design, complete rethinking of a whole component, big shifts in database schema, wholesale rework to the GUI, etc., need to be absorbed in the design phase without an iota of grief.

[One of these days maybe I’ll blog about Computer Aided Software Engineering (CASE) technology. During one era of my life I spent eight years building such technology to automate the blueprint process; hence this subject remains very dear to my heart.]

RELATED POSTS:

Super Consultants

Custom Software Scope Changes (Not)

Scalability and Sustainability in Large Information Sharing Systems

Custom Software Scope Changes (Not)

[If you have never been involved in a custom software engagement (e.g., on the software builder side, customer buyer side, contract law side, etc.), there is no need to read this post.]

I spent roughly 22 years of my life building somewhere between 150-200 custom software systems ranging from accounting systems, llama genealogy systems, labor reporting systems, airport profitability systems, huge consolidation consumer data warehouses, and sewer flow modeling systems to the first versions of NORA.

There was one particularly interesting lesson from these days:

“Custom software change orders CLAIMED by builders … are actually more often changes in understanding that come to light as the visions between parties are forced to reconcile.”

Here is how this goes: The buyer describes what they want to the builder.  The builder captures this vision in the form of requirements, features, design layouts, etc.  This exchange of vision continues until the builders and buyers think they are in synch.  The builder starts to build.  The buyer starts to see the system come to life.  The buyer notes that what he sees is not quite what he had in mind and calls for some adjustments.  The builder calls this a change order.

What is really happening is the visions between parties are being forced to reconcile as the system takes shape in the real world.

In my book, this is not a scope change.  This only demonstrates that both parties had something different in mind on day one.

There is only one way to safely avoid this all too frequent problem and that is blueprints.  And I am not talking about a few screen sketches and report headers.  I am talking about robust architectural plans: complete screen layouts with error messages, full report mock-ups containing realistic data and sub-totals.  I am talking about a degree of design completeness that the specifications could be used to simulate (e.g., in paper form) the use of the whole system by each type of user.

No one builds a high-rise building let alone a doghouse without blueprints.  Otherwise, there is an extraordinary risk of a) an abandoned project or b) the creation of a Dr. Seuss “Who House.”

On a related note: some think that rapid prototyping of big complex systems can shortcut a comprehensive design phase.  With few exceptions, I think this is ridiculous.  [I will elaborate on this is a coming post.  But in the mean time, as a teaser, I have a single test question that determines if a custom software system has been well-conceived.  Once the system is all done, knowing what you know now, would you have built it the same way?]

Is the custom software world still this way?

RELATED POSTS:
Super Consultants

Scalability and Sustainability in Large Information Sharing Systems

Malaysia Ironman versus South Africa Ironman – “Tastes like Mango”

In February 2008 I did the Malaysia Ironman, which took me nearly 15 hours. This last Sunday, seven weeks later, I did the South Africa Ironman, which took me just over 12.5 hours, missing my best time by just five minutes. In hindsight I now realize I should not have stopped to take a 10 minute shower in the middle of the run. My bad.

You learn something in every race. And some things are never as they appear. Take the guy I ran past last Sunday in South Africa. I could tell that he had a bit of a hygiene problem going on. So I said, “Hey, I think I should tell you that you have some diarrhea seeping through the back of your run trunks.” He says “You mean it looks like I ’shat’” my pants?” I nod. He then proceeds to take his right hand to scrape the back of his shorts. He can now see it as he has this brown gunk on his hand. He looks at it. Smells it. Then licks it! He looks at me and says “Tastes like mango.” Apparently some mango-flavored supplement ended up in the wrong place. However, had I been thinking more quickly I would have said “Did you have mangos for dinner last night?” In any case, he thanks me, shakes my hand … mango poopy material and all … and then we part ways.

Here is another big lesson that I seem to learn over and over. “Sighting” during open water swims is important. In this most recent race I did the first half in 38 minutes, yet the second half took me an extra seven minutes. Why? Well, my big mistake was selecting a cloud that was hovering way out over the Indian Ocean as a sighting point. About 10 minutes later while I was basking in how lucky I was not to be kicked and scratched by other swimmers – it dawned on me that I had not seen anyone in quite some time. So I poked my head out of the water to locate the next race buoy only to discovered I was actually en route to India itself.  Great white shark territory, I was thinking – and without all the feeding options (the other athletes) … just me.

And on that note, here are a few new triathlon tips for those like me who don’t actually have the time to train properly:

• Go long. If you can only ride 2-5 times a month, make each ride super long (75 to 200 miles) and hard – hills are good. Same goes with runs.
• Try a full marathon on a treadmill. What is great training about this is the monotony.
• Swim training. Never. The training time it takes to get faster is not worth the effort when you are in my hacker category. (In my first triathlon I did the stroke known as the “backfloat” which by the way, on a related note, was shortly after I asked triathlete legend Scott Tinley just before the race if fast people can actually swim the whole distance freestyle. I recall he looked at me in a disgusted fashion.)
• Brick workouts (practicing going from bike to run) are hard and take more time. There is probably a reason they are called bricks. I think I have only done three bricks in my entire life. Try to avoid these.
• Swimming. Don’t sight on clouds, boats, or other things that move.
• Get a time trial bike and stay down on those aero bars the whole time (unless out of your saddle climbing). I bought a Cervelo P3C bike about a month before my last race. Had four rides on it before the South Africa race getting used to the new position (two rides at 38 miles, one a 58 mile ride, and one 200 miler). This bike gave me my best bike time ever in an Ironman race, shaving nearly 45 minutes off of my previous best time. I almost broke 5.5 hours (5h33m) averaging 19.6mph!
• Drinking (alcohol) the night before the race is approved. It helps take the stress off the night before the race. Tell your friends you are “carb loading!”
• During the race don’t drink weird stuff you have not trained with on the race course. If you do try something new. Only take a sip or two and then see how you feel in 30 minutes before ingesting any more.  Stomach cramps suck.
• Shave (the undercarriage) the morning of the race. Otherwise, if you shave the night before your morning micro stubble will serve as sandpaper. Ouch-O-rama.
• After shaving the same morning of the South Africa race, I boldly slipped on some brand new, untested, tri shorts for the race. Ouch-O-rama times 100. A very bad idea. They caused such severe chafing my huevos were bleeding by race end. I could barely walk. Girlfriend says it is one of the grossest things she has ever seen. I’m simply hoping there is no permanent scarring. Reminder: don’t try untested things race day.
• Water and nutrition will make or break your race. I continue to remain uncertain about the importance of mangos.

Now a few race specifics.

Malaysia Ironman (Langkawi), February 2008. Beautiful country. Extraordinarily nice people. The swim is a “no wet suit” swim. Aside from this messing up the swim times of hackers like myself … the real problem was the stinging sea lice (some called it plankton). I did not know what was stinging me. But whatever it was … it was getting caught in my chest hair (which was behaving like a little net). Key point: It is hard to maintain a decent swim stroke while trying to beat these little critters out of your chest hair. Tip: In such conditions, maybe try shaving all that hair off so that less of these critters get stuck on you. The bike course was smooth. Some portions were closed to cars. Others portions were not closed. Watch out for the begging kids on the bike race course – there were a few – they appeared to think one of us might pull over to give them money! Anyway, by the time you get to the run, the temperature and humidity are killing you. On my race day it was something like 32 degree C (90 degrees F) and 40-50% humidity. To add to the suffering, some parts of the race course are right next to heavy traffic (smog) and, what appears to be, open sewers. I spotted some athletes (mid run) lying down in bus stops, others being assisted by ambulances, and quite a few simply puking their guts up. Looked to me like they were all from Japan! (This is a popular race if you live in Japan). The Singaporeans, on the other hand, seemed to fare very well (to know humidity is to love humidity – because I live in Las Vegas, you can guess how I feel about humidity). Finally, this race course itself is also not even remotely spectator friendly. You will hardly ever see anyone. Needless to say, this was my least favorite Ironman race so far.

South Africa Ironman (Port Elizabeth), April 2008. Very smooth waters on race day (I heard this was not that common). Extraordinary bike and run course – all roads in excellent shape and 100% closed to traffic! Simply fantastic. Very professionally organized. And this race course is the most spectator friendly I’ve seen – in part because you see your friends at least three times on the bike ride and up to six times on the run! This was my favorite race of the eight Ironman-sanctioned events I’ve done. Only one word of caution:  South Africa is suffering from a power shortage, which is evidenced by the roaming (scheduled) blackouts. The point being if you decide to get out and cycle the course before the race, pay special attention when passing through intersections with disabled traffic signals! And finally, if you see the beautiful little shower facility in the middle of the run course … and you are positioned to possibly beat your best time … don’t take off your socks, shoes, hat and shirt … for a dreamy little 10 minute shower (asking around for soap) in the middle of your race … unless it is really going to be worth it … which for me, it was!

 

RELATED POSTS:

Hacking the 2007 Brazil Ironman Triathlon in Florianopolis (May 27, 2007) – Strategy, Tragedy and 100% Pure Agava Tequila

Preparing for the 2007 New Zealand Ironman in Singapore?

Handicapped at the 2006 Arizona Ironman

Surviving the 2006 France Ironman and How Intelligent are Chimpanzees?

Dumb and Dumber: Consequences of the 2006 Silverman Triathlon

What sharks? Reflections on the 2005 Western Australia Ironman

 

Photosynth / Infosynth

Photosynth is the coolest technology I have seen in recent memory. It is also the most graphic example I know of that demonstrates the power of context accumulation.

As I noted in this post last week, the only way to make any real sense of the big picture is to first stitch together all of the atomic-level observations (puzzle pieces) into context (pictures).

With this in mind, take a look at this exceptional video about “Photosynth” presented by Blaise Aguera y Arcas at a TED conference.  

Now imagine the process of stitching together not just digital images … but all available data – across disparate data types (e.g., structured, unstructured text, images, video, audio, etc.).

When I speak of Context, this is exactly what I mean.  

So after seeing Photosynth ... this made me think “n” sensor context accumulation could just as easily be called “Infosynth.”

These context engines will be used to deliver laser-precise relevance in support of next generation: user search; customer service; risk mitigation; ultra-weak signal detection; and so much more. 

PRIVACY RAMIFICATIONS? Big time. Nonetheless, consumers are going to love the new industry offerings that context engines will enable. Stay tuned for a forthcoming post on my Responsible Innovation thread about what technologists might want to "design in" to these next generation systems in hopes of making these future systems more palatable from the privacy and civil liberties perspective.

RELATED POSTS:

Algorithms At Dead-End: Cannot Squeeze Knowledge Out Of A Pixel

Context: A Must-Have and Thoughts on Getting Some …

Federated Discovery vs. Persistent Context – Enterprise Intelligence Requires the Later

To Know Semantic Reconciliation is to Love Semantic Reconciliation

More Data is Better, Proceed With Caution

Accumulating Context: Now or Never

Big Breakthrough in Performance: Tuning Tips for Incremental Learning Systems

Responsible Innovation: Staying Engaged with the Privacy Community

My Broken Neck: A 20 Year Anniversary

TWENTY YEARS AGO TODAY … I broke my neck in a car accident which rendered me a complete quadriplegic for a short while. The only reason I am alive today, with relatively full functionality, is thanks to some stranger who saved my life and then disappeared without a trace.

On Leap Day 1988 in San Mateo, California I went on a BMW test drive. The salesman was driving. He was showing off the handing capabilities of the car on back roads. He lost control as we approached a turn which resulted in us plowing into a dirt embankment at what was estimated at 63 miles per hour. I was in the rear seat behind the driver – in a seatbelt, without an airbag.

While my seatbelt secured my body, my head continued to travel forward at 63 miles per hour. This resulted in a C2 spinal fracture (the same break that Superman’s Christopher Reeves experienced). I ended up sitting there in the car – each hand resting palm down on each leg, perfectly placed. Unable to hold my head up, I starred towards my lap fully aware we had crashed and to boot realized I was totally paralyzed and unable to breathe (as my hanging head blocked my wind pipe).

I had always wondered as a kid what would be the final minutes of thinking if you knew death was imminent. So there I sat staring at my hands slowly changing color from that of the living to that of the dead. And so it seemed this day would end my 23 years of Earthly habitation.

I do not know how many minutes I was forced to witness my slow death … more than a few minutes for sure and less than six for sure.

My door flies open, and only my door. An Asian man leans into the car and looks up into my face and says "Can you breathe?" I lip synch "No" … three times.  He says "Do you want me to lift your head?" So, I lip synch "Yes" once. He proceeds to hold my head up in a hyper-extended fashion with perfection … as if medically trained. Once my head is extended I find I can breath. Move? No. Breathe, yes!

He holds my head in position with his arms fully extended for nearly thirty minutes until the ambulances arrive (heads are heavy and the fact this person could maintain this position for so long is in itself a miracle). Had he tried to rest or settle my head to assist the others in the car I would, without a doubt, be dead or a quadriplegic today.

The paramedics step in and take possession of my head.

Then … poof this savior disappears! No sign of him.  No witnesses, no reference in the police report.  Nothing.

The doctors told my parents I would most likely be paralyzed for life. No one told me that though … and so, despite this prognosis ... I recovered.

And recover I did - over the next four or five months, although not fully. To this day, I suffer from a very rare condition called Brown-Sequard Syndrome. In short, the center of my spinal cord in the vicinity of the C2 vertebrae is now dead. As a result, the right side of my body has a very lower ability to sense hot, cold, and pain. And the nervous system on the left side of my body is hypersensitive and I have a noticeable degree of muscle atrophy on the left side as my brain does not talk to all of those muscles anymore.

Lucky? Yep.

Does such an accident reorient one to the value of life and priorities? True, although oddly this new think only lasted about six months!

What are my thoughts about death now? Every day since February 29th, 1988 has been an extra day.

Regrets? I only wish I could locate and thank the person who saved me. Maybe he wonders what came of my condition and if he had done the right thing. My parents, my children, my girlfriend, and I would like to convey our thanks.

Dear Mr. Stranger: Thank you.

RELATED POSTS:

My Mother’s Blog Post: "20 Years Ago Today"

Algorithms At Dead-End: Cannot Squeeze Knowledge Out Of A Pixel

Have you ever heard the expression “climbing trees to get to the moon”?  This means that while one can make progress inching along (up a tree in this case) … if one stands back to look at the big picture … no matter how successful one is at climbing trees … it is quite obvious they are never going to get to the moon.

I have news … for those waiting for big breakthroughs in algorithms to better make sense of transactional data (e.g., to lower false positives/negatives), they are going to be waiting a long time (actually, it's worse, forever).

Using algorithms to analyze transactions is like analyzing a single pixel.  No matter how much computing power, time and sophistication of algorithms … determining if the “red pixel” is a fire versus a fire engine simply isn’t a precision activity.

Next generation, real-world aware systems are going to FIRST apply inbound transactions (i.e., pixels) to earlier observations in order to construct context (i.e., pictures).  Then, and only then, will algorithms be able to more accurately determine the relevance of new transactions.  There are no short cuts.

Assembling pixels into pictures is the story of Context Accumulation. 

But how do pixels get assembled into pictures?  There is only one way to accomplish this and that starts with “feature extraction” and I wrote a bit about this in my post called “Context: A Must-Have and Thoughts on Getting Some …”  Just to be clear, algorithms are, of course, required on pixels to perform “feature extraction” and there is room for extraordinary improvement in this area (e.g., see point #5 in the above blog post).

Persistent Context and Perpetual Analytics are the most significant hurdles necessary to deliver the next generation of intelligent systems.

AND FOR THE RECORD: Don’t expect Google’s search analytics to get much better as this technology is near the end of its road as well.  The reason being is; they are applying analytics to documents … which are really just context-less pixels.  Quantum leaps forward in search are going to come from context accumulation.

RELATED POSTS:

Context: A Must-Have and Thoughts on Getting Some …

Accumulating Context: Now or Never

Sensing Importance: Now or Never

Enterprise Intelligence – My Presentation at the third Annual Web 2.0 Summit

Federated Discovery vs. Persistent Context – Enterprise Intelligence Requires the Later

Streaming Analytics vs. Perpetual Analytics (Advantages of Windowless Thinking)

Enterprise Intelligence: Conference Proceedings from TTI/Vanguard (December 2006)

Intelligent Organizations – Assembling Context and The Proof is in the Chimp!

It’s All About the Librarian! New Paradigms in Enterprise Discovery and Awareness

To Know Semantic Reconciliation is to Love Semantic Reconciliation

More Data is Better, Proceed With Caution

Virtual Reality: There Is No Place Like Home

Increasingly over the last year, I have been asked to share my thoughts about virtual worlds (e.g., Second Life and World of Warcraft).  After repeated provocation, I took a peek into these interactive 3D La-La-Lands to see what is up.  Here are a few of my core conclusions:

1.    Virtual realities will end up consuming the attention of a substantial number of humans and this will happen more quickly than most may think.
2.    Data synchronization between the real world and virtual worlds will increase the relevance of virtual worlds.
3.    Along with the eyeballs of transacting consumers will come increased corporate investment thus driving more relevance and more growth.
4.    Investors in virtual world physics re-engineering will possess a distinct advantage in virtual worlds.
5.    As with any tool, a very small percentage of the population will use virtual worlds for criminal activities.

Here are a few details related to these points.

Virtual reality: soon serving the masses.  As these alternate worlds become more immersive (i.e., ability to hold ones attention when in the virtual space) and accessible (think One Laptop Per Child), I think it is possible that a half billion people show up.  How soon?  In six to ten years – maybe faster.  Why?  Because there are a lot of people on Earth that would rather exist in a synthetic world as opposed to their real world.  Hmmm … shanty town, nagging spouse, or insurmountable odds versus a stimulating environment with near limitless potential to reinvent oneself.

Cross-reality synchronization.  Imagine taking heat sensors in a real-world data center and publishing these into a virtual space which is physically configured like the real data center.  The difference being that the immersed person can now physically visualize the temperature distribution in the data center.  This is already being done.  Then move something in the physical world and it moves in the virtual world at the same time, automatically.  I wouldn’t be surprised if this is already happening in some context, somewhere.  As well, the inverse: There is supposedly a fellow who has an island in Second Life with a surveillance mechanism implemented that sends him a real-world email or text message whenever someone steps foot onto his island.  Long story short, if one wants to look at something specific, if the real and virtual worlds are synchronized, it’s going to be cheaper, faster and will burn less carbon if one takes the virtual option.

Real economic growth in unreal worlds.  Have you heard about the real estate developer in Second Life that has made $1,000,000 (real) US dollars?  True.  Linden dollars, the monetary unit in Second Life, have their own currency exchange to US dollars called the LindeX – a currency market apparently moving millions of dollars a month between the virtual and real worlds.  Point being, if a billion people show up in virtual spaces, each on average spending only eleven cents ($0.11) a month – this amounts to a real growth market which will trigger further industry investment.  Consequently: more people arrive. 

Virtual world physics re-engineering.  Through serendipity, careful study, and/or experimentation it is possible to develop capabilities within virtual reality that other participants, or in some cases even the creator, cannot fathom.  The first such instance I heard of five or six years ago involved a player who figured out he could climb walls by mounting deactivated explosive devices on a wall.  Placing one above the other, the avatar cleverly scaled the wall.  He climbed so high that he moved beyond the rendered space … into a region of the game where all that was visible was texture-less grid lines.  In a more recent example, in Second Life an individual created a covert listening device the size of a single pixel -- then placed this pixel inside some object.  Later when the object was near a conversation, all communications were echoed to a third party unbeknownst to the victims.  Prior to this event many players in Second Life would not have considered this possible.  Game physics re-engineering is also happening in World of Warcraft (where it is called "Theorycraft").  In this virtual world, one expert explained it to me this way “[we are] unwrapping the mathematics and developing a perception of space and time in relation to the virtual world, that determines which combination of attacks or defenses have the greatest efficacy.”  This info is then shared with colleagues in password protected chat rooms.  Using this knowledge delivers extraordinary advantage, namely lethality per second optimizations, hence the importance of keeping this specialized knowledge to a privileged few as long as possible.  By the way, let’s not forget that we are re-engineering the physics here on Earth in a similar manner.  Heck, ten thousand years ago, who would have conceived of the possibility that spaceships could be devised to take man to the moon and back! 

Tools are tools.  Are virtual spaces dangerous?  Well, is a phone, the Internet and email dangerous?  Nope, not for the most part, in fact the opposite, as the social and economic values of these technologies far outweigh the consequences of misuse.  Sure bad actors will continue to use the best tools they can get their hands on too.  And with this behavior, as more bad actors show up … the folks paid to “protect” us will venture into these virtual spaces in an effort to detect and preempt.  Hence some of my quotes in this recent Washington Post story “Spies Battleground Turns Virtual.”

And finally, how will you know virtual worlds are starting to collide with your own real world?  Watch for this sign: someone wants to chat with you while showing you something and they explain the best way to do this efficiently is for you to “step in” [to the virtual world that is].

RELATED POSTS:
Ghost in the Machine?