Articles...

Copyright © 2009 Corvus International Inc.  All Rights Reserved

Home      About Corvus       Contact Us       Articles/Resources       Clients          Affiliations  

The only kind of learning which significantly
influences behavior is self-discovered or
self-appropriated learning--truth that has
been assimilated in experience.


                        
   Carl Ransom Rogers (1902 - 1987)
                      American Psychologist

                       from Freedom to Learn
 


ACM DL Author-ize serviceWhen executives code

Phillip Armour
Communications of the ACM - Multimodal interfaces that flex, adapt, and persist, 2004

 


The Software Paradigm                                                       


In my column, I have been pursuing a chain of logic related to what Peter Drucker called "The Knowledge Economy".   Specifically, if Drucker was correct, the asset basis of the world is changing away from raw materials, manufacturing capability, and money and moving to knowledge, where would we keep this precious asset?  Well, in software of course.

But what happens to companies as this transition occurs?  If they are truly invested in this knowledge economy, no matter what their core business, they inevitably become software development companies.  Whether they want to or not, whether they recognize this change or not, whether they are prepared for it or not--this inexorable pressure converts what they do into knowledge and converts that knowledge into software.  But what would an executive do if he or she woke up one morning and suddenly realized "Omigosh!  We've become a software company!  And I know nothing about building software!  I'm a [manufacturing | marketing | accounting | research | management | financial] (pick one) person!" 

The Software Symposium                                                   


For a number of years, I ran a three-day symposium on the software paradigm.  On Day One, we covered the topics I address in my column and book.  We talked about lifecycles and organizational maturity models, design methods and testing approaches, programming languages and software packages.  We also played some games to give people the "feel" of what it takes to build software.

Then on Day Two I had them program computers.  With a normal group of 20 people, I would divide them into four groups of five people.  I gave them their basic system concept, pointed them to a set of computers, and demanded (in advance of a detailed specification of requirements, of course) that they produce a functioning system by 3:30pm that afternoon.

System Concept                                                         


Was simple: produce an interactive website that would act as a useful resource to executives who had just woken up to the fact that their company had just morphed into a software organization (don't you just love recursion?).  This way, they were their own customers and could if they wished create their own detailed requirements (!).  My requirements were simply that it would be a website, it would be useful, and it would be interactive.  The last point was very important.  I did not want people to simply produce a website that consisted only of pages to be read--that is an electronic version of paper, it is not software.  To be software, it would have to execute.

These requirements would force the executives to revisit yesterday's lectures and, if they were clever, even try to recreate the "games" in some interactive form*.  For other requirements they simply need to ask themselves "what would be useful to me?"  Then they would have to:

  •  Decide on a lifecycle: prototype/Iterative--how many iterations? Waterfall--what phases? Spiral--where's the risk?

  •  Design their project: who would do what? How would they manage the activities?

  •  Design their workspace: how would they use which computers?  What tools? (though these were mostly provided)

  •  Develop requirements: building on the basics I gave them

  •  Design the system: specifically the website look and feel/navigation framework

  •  Design components: eg., web pages

  •  Build components

  •  Test components

  •  Integrate components

  •  System test

  •  Present their solution (at 3:30pm)

Guess What They Did?                                               


These executives did not actually build anything that worked.  They produced good plans which they didn't use.  They designed disciplined lifecycles which they never applied.  They created code that they patched together, didn't test and then lost.  Basically, they HACKED.  From beginning to end, they randomly coded and played around.  They built:


things that scrolled and scrolled and scrolled and scrolled and scrolled and scrolled and scrolled and...                                                            

things that bounced and...    things in different fonts and Odd colors and...

Cute things that moved and...          some things that were just plain weird


But they didn't produce anything that actually worked!  Not ever.  They just played. 

These executives did exactly what they routinely accuse software developers of doing: working on the interesting stuff, the "creative" stuff, the cool stuff without paying attention to the actual needs of the customer or the organization.

Here's why:

  •  The area of least knowledge for the executives was coding

  •  Therefore, they will learn most (read: acquire the most knowledge) by practicing their coding skills--which is what they did.  For the business of acquiring knowledge, we get the greatest return looking in our area of greatest ignorance

  •  They rapidly became seduced by the two great motivators of the software engineer:
        > They were learning
        > They were creating

    These two powerful drives subordinated any attempt at "discipline" and "rigor" in building systems; even to the point of not actually building anything.

The Moral of the Story

The job of the executive running a software business (as most businesses will become) is NOT to quash the learning and creative drives of the software developers, but to encourage, harness, and direct them.
 

   * Reproduce games?  You kidding?  Never happened.  In fact, despite the fact that using the web creation wizard a website could have been built in perhaps an hour or so, we never actually got a functioning website of any sort.  What happens when executives code?  Not much it seems.

When Executives Code...