The life of a hero – Doug Engelbart 1930 – 2013

July 8, 2013

douglas-engelbart-at-sri-8-oct-68-demo-rehearsalMENLO PARK, Calif.—July 3, 2013—Computing visionary Douglas C. Engelbart, Ph.D, passed away peacefully at his home in Atherton, California on July 2, 2013. He was 88 years old. Engelbart’s work is the very foundation of personal computing and the Internet. His vision was to solve humanity’s most important problems by using computers to improve communication and collaboration. He was world famous for his invention of the computer mouse and the origins of interactive computing. — SRI International press release

1968 – The Mother of All Demos

I entered Stanford University’s Computer Science (CS) Department in June, 1966, less than a year after its opening, and remained a graduate student there for the next 6 years. The graduate students in CS came from mixed backgrounds, since there had been no definition of CS until around this time.

In the winter of 1968, many of us drove up to San Francisco to attend the Fall Joint Computer Conference at Brooks Hall. And so we were there in the audience when Doug Engelbart took the stage to demonstrate his working model of a system that would “augment human intelligence.”

As I recall the event, Doug was in a chair that had two fixed, flat arms, like the ones you find in schools, except that this chair also could swivel. On the left side he held a mouse, and on the right was a 5-key keyboard. He could type with the 5 keys by pressing one or multiple keys at the same time (this gives you 31 combinations of keystrokes, and some keystrokes changed the “case” to give more options). There was a screen, and the screen contents were also projected onto a large screen that the audience could see.

Steven Levy in his 1994 book, Insanely Great: The Life and Times of Macintosh, the Computer That Changed Everything, describes the event as “a calming voice from Mission Control as the truly final frontier whizzed before their eyes. It was the mother of all demos.”

The impact of this demo was not so great at the time. We thought that he had some interesting ideas, such as “windows” that appeared to be sheets of paper overlapping each other on a “desktop.” He also had pull-down menus and something like hyperlinks. Quite far-out stuff. But what made the demo stand out compared to everything else in computing at the time was the fact that Doug – a SINGLE USER – was employing the full computing power of a system running down in Menlo Park that cost hundreds of thousands of dollars. We didn’t think of computers as “personal” in any sense in those days.

Transition to Xerox PARC

Within a few years, Xerox had founded the Palo Alto Research Center (PARC), and in time, the ideas that Doug had developed made the transition to Xerox PARC and were refined in the Alto personal system for internal use at PARC. (For more on PARC, see Dealers of Lightning by Michael Hiltzik)

Apple Lisa – bringing the Xerox Alto/Star to Apple

In 1979, I started working for Apple Computer as a hardware designer on the Lisa team. We initially were implementing a microprogrammed version of UCSD Pascal, but soon dropped the design to go with the Motorola 68000 CPU chip. About this time, Steve Jobs made his now-famous visit to Xerox PARC and came back very excited about the user interface – windows, pull-down menus, bit-mapped graphics – that had evolved from Doug Englebart’s work.

The Lisa software team acquired numerous people from Xerox PARC and that led to the second commercial version of Doug Engelbart’s ideas (the first was the Xerox STAR, a $20,000 system). The Lisa (1983) reduced that cost to about $10,000; but it wasn’t until the Macintosh (1984) that Doug’s ideas were found on a truly personal (and affordable) computer.

1996 – Quantum Strategic Teams

Meanwhile, I spent 10 years consulting for a variety of firms in Silicon Valley. One of those was Quantum, a hard disk drive maker. In 1993, I hired into Quantum to build a new department called Systems Engineering.

In 1996, Quantum invited me to join a strategic planning effort that recruited 16 employees – two teams of 8 – to look 10 years ahead and set Quantum’s direction for the future, using a process outlined in Prahalad and Hamel’s book, Competing for the Future. We were encouraged to engage the forward-thinkers of the Bay Area to stimulate our ideas. Remembering Doug Engelbart’s demo, I located Doug and invited him to come to Quantum for a day.

By this time, Doug’s office was lodged in Fremont, in a corner of a building where Logitech made computer mice and other gear. Pierluigi Zappacosta, founder of Logitech, was grateful to Doug for his inventions and offered him free use of this space.

During Doug’s day at Quantum, I learned more about his approach to research. In particular, there were three things that stood out for me:

First, there was what Doug showed as a spiral – the iterative improvement in human capability that comes from improving the tools a person uses. As the tools improve, the person can fashion additional and further-improved tools to keep the spiral growing.

Second, Doug was focused on the individual at work, including the ways in which an individual communicates with another individual. In this context, he was the prototype of the original “user experience designer” – a person who is concerned only with how things appear to the user and what the user can accomplish.

Third, Doug clearly understood and relied on Moore’s Law, the cost trend that brings double the computing power to a constant-cost chip every 1.5 to 2 years. For Doug, this is what was guaranteed to bring – within a few decades from 1968 –sufficient computing resources at reasonable cost into the hands of the individual.

What should we learn from this man’s life?

The lives of the heroes, someone once said, are not to be taken as models, but as lessons. Here are some of the lessons I believe we should learn from Doug’s life.

A. The life of a visionary is often lonely, because he or she can see what is to come long before others can. In Doug’s case, it took 30 years to arrive at the fruition of his ideas. He was fortunate that he lived to see that arrival.

B. Not all visionaries get to run a company and drive it to their vision. Steve Jobs was a rare exception, and even he had real success only on the third try.

C. When you’re inventing things, you have to plan to throw away a lot of prototypes. This is a test of persistence and courage. Doug had these traits.

D. Ultimate success comes from patient work towards a goal clearly seen. The critical components of such work are the patience and the clarity. Few of us maintain the level of clarity that Doug Engelbart achieved, and fewer still have the patience to return again and again to the vision.

We should all feel inspired by Doug’s life: not by his “success” as measured in the commercial world, but by the example he set of steady vision, patiently explained and consistently followed.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , , , ,

Why do we need so much software?

April 18, 2013

Software is everywhere, but you can’t see it.  You know it’s in your phone, your computer, your home appliances and your electric meter, but do you know why?  This article explores the reasons for the explosion of software.

 

Computers have taken over many functions that used to be performed by other equipment and by people.  While computers were originally developed to compute, they now control, communicate and manage things that require much more than just “computing.”

Moore’s Law is the term used to describe the geometric increase over the past 50 years of the number of electronic digital circuits that can be placed on a fixed-size piece of silicon.  A corresponding decrease in the cost of those circuits has driven the digital revolution – replacing nearly everything that used electrical or electronic circuits with their digital equivalent.

A “digital equivalent” of course is not really equivalent, because it consists of a computer.  Each computer, no matter how small or large, includes a processor, memory, and ways of moving data in and out.  All of the activity in a processor happens as a result of executing a program – a series of instructions that are stored in the memory.  And programs are software.

Managing the activities of a computer requires – a computer.  The operating system of a computer is the set of programs that are concerned with managing resources and activities inside the computer.  This is not trivial, because programs are constructed of very simple instructions, and there are a lot of resources and lots of activities inside each computer.  For example, what happens when data is moved in or out of the computer?  Where does it get stored?  How does it get checked and how does it get moved to a more permanent location, such as a disk?  These are all activities an operating system is concerned with.

Keeping track of stored data usually is done by a file system, which is another part of most operating systems.  Turning power on and off for parts of the system that are not used all of the time is another function of system software on, for example, a mobile phone.  This extends the battery life.

Furthermore, thousands of conditions can occur while the computer is operating, such as errors in moving data or interruptions due to user interaction (like typing on a keyboard or touching a screen icon).  Each condition has to be dealt with in a way that won’t stop the computer.

As computers have become widely used, specialized programs have come to be part of the standard repertoire.  Programs dealing with databases (such as a customer list with all of their purchases), audio and video data (such as YouTube videos and podcasts), and photos (such as your smartphone pictures) have become standard requirements for computers that we use in business and at home.

Communications systems – including the Internet – have incorporated computers to manage delivery of data globally; and services such as Google have developed enormous dictionaries of everything on the Internet (and also things like videos and books) that can be searched.  The hardware of each of these, while massive and widespread, is dwarfed by the effort put into creating software that keeps them running and delivering the latest services.

Competition between the latest start-ups today is mostly in the domain of software.  Delivering new services in the Internet age requires deep understanding of software and how to leverage what was developed by others last week to make something new this week.

Software and the tools for developing it are the context in which the best and brightest of the current generation are expressing their creativity and becoming part of the global economy.  You can expect more software from more software designers to result in a lot of unexpected new products and services.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , ,

Trust, truth and talking things through

April 10, 2012

Collaboration thrives on trust, truth and a willingness to talk things through.  When these elements are present for people in a team or in a department, those people take responsibility, use their authority wisely, and develop a climate of openness.

Here are key principles and other aspects of each of these elements.

Trust

I trust you if you speak and act with respect and maintain that respect when you communicate with others about me

Team members gain trust by doing what they say they will do.  But even more important in gaining trust is being respectful when speaking to a person or to someone else about a person.

In addition, a manager should always defend the team’s boundaries.  This includes alerting the team when there is a potential conflict with another team or manager and backing up the team when it needed.

Truth

If you believe you’re never wrong, you should not be on a team or in management.

Truthfulness is, of course, saying what’s true and not saying what’s false.  But much more important is being willing to own your own mistakes and misunderstandings.  By being open to correcting yourself, you make space for me to do the same.  You also make willingness to adapt and learn part of our shared culture.

A lot of the work of business is finding out what’s true – about a market, about a product, or about the world.  As long as we’re open to learning, which means there are things we don’t know, we encourage real inquiry that leads to knowledge and good decisions.

Talking things through

 “Talking things through” is being willing to address conflict.

Since conflict is inevitable, we need healthy ways to deal with it.  The best way is to acknowledge its existence right away, but not by making the other person wrong.  We can state what we see as disagreement without disrespect or rancor.  Start from assuming that the other person has a valid reason for their view.  Then start listening rather than arguing.

While compromise is one way to resolve conflict, there is a better way.  Begin by understanding the values and intentions of the other person.  Then search for ways to resolve the conflict while advancing both your own and the other person’s values.

What about incentives?  People who are collaborating successfully need very little additional incentives, because the process of collaboration – and the successes it generates – are rewarding enough.  Create an environment where there is trust, truth and talking things through, and you need only get out of the way.

Filed Under: Agile Management Tagged With: , , , , , , ,

Agile Clouds

December 21, 2011

Buzzwords abound in the Business IT world. You can’t ignore these words because they come at you from all sides. To help you cope with the possible hype you’ve been hearing, I offer you a brief overview of the realities of two of them– “Cloud” and “Agile”.

The Cloud

Everyone touts “the Cloud” as the latest thing, yet many aspects of the Cloud have been around for years. If you’re using Salesforce.com, for example, you’ve had software as a service (SaaS) for as long as you’ve been a subscriber. In my office, we use a CRM (customer-relationship manager) service named Highrise by a company called 37Signals. There are many satisfied users of these cloud services, but it’s best if you understand the tradeoffs and pitfalls. Here’s a quick summary:

What’s most unusual about the Cloud? – it accommodates temporary load variations

Using software that’s running “in the Cloud” gives you the capability to radically change your usage of the computers. So if you have a temporary load that is 100 times your average load, you can “provision” a bunch of servers and cover your needs in just a few minutes’ interaction with the cloud service.

What’s the biggest caveat about using the Cloud? – you have to be using standardized services

Cloud service providers can give you what you want in a moment’s notice. But unless you’re using a service that is standard – that is, not much different from everybody’s else’s service – you will not find it economical. So don’t look to cloud services to differentiate you from your competitors, because they are probably using the same or a similar service, too.

What’s the payoff of using the Cloud? – OpEx, not CapEx

You pay only for what you use, and it’s usually a lot less than the cost of provisioning your own data center and buying the software. So using the cloud lets you get IT work done efficiently on operating expenses alone.

What else could be a problem in using the Cloud?

  1. Security – don’t plan to put your most confidential data into the cloud. For the data you do put in the cloud, make sure you have adequate backup and restore capability, or suitable data duplication.
  2. Availability – be sure to check on service level agreements (SLAs) from your cloud providers. Think about how many minutes of downtime a year you can afford, then compare the offerings.
  3. Competitive services – there aren’t many cloud service standards yet, so moving from one cloud provider to another can be a problem.
  4. Rogue IT – If you’re managing IT for a large organization, you may discover that department managers are buying their own cloud services. This may be efficient and effective for them, but it could undermine your efforts to get IT to be consistent and effective across the organization. Get out in front of your users’ needs, and offer consulting on cloud services to your departments.

For a longer essay on the ups and downs of cloud services, I recommend you read Robert Keahey’s article titled, “The CFO’s Guide to the Cloud”.

Agile

Agile software development originated with the “Agile Manifesto” in 2001. I like to describe it as a bunch of software developers who got together and said to themselves, “We’ve been so badly managed for so long, surely we can do better ourselves.” So they laid down 4 values and 12 principles for software development. Since then, Agile has proven to be 2 to 3 times more efficient than previous “waterfall” methods for many types of software development. And the Agile principles have begun to be taken into other areas of management. Here are a few key things you should know about Agile:

What’s most unusual about Agile? – progress is more visible

Agile methods work by dividing up a large project into increments that can be done in short intervals. The interval chosen is usually 2 or 3 weeks. At the end of each interval, the project team demonstrates working software. Since you can see the software working sooner and more often, you get more confidence that the claimed progress is real, because you can see it.

What’s the biggest caveat about using Agile? – it requires more involvement by business people.

A development team in an Agile project requires daily access to a business person who is responsible for the results. This guarantees that software developers can talk over what the requirements really mean. It also requires the business person to be on-call every day, as well as present in person at the end-of-iteration reviews every 2 weeks. Don’t expect an Agile team to be effective if you don’t provide for this level of time commitment by one of the business leaders.

What’s the payoff of using Agile? – you can keep up with changes in the market and in your business priorities.

At each interval the priorities are set for what should be done in the next iteration, so you can adapt the project to changing conditions as you go. This helps to keep you from paying for a lot of work on the wrong thing. In fact, this could allow you to kill a project after only 10% of it is done, rather than having to wait until 60% to 80% of it is done to find out it’s the wrong thing.

What are other benefits of using Agile? – Agile could infect your company’s project management system and make everything you do more efficient. At the very least, using Agile for software development in IT will make your business people and your IT people work closer together on major developments. And that couldn’t be bad, right?

 

Filed Under: Agile Management Tagged With: ,

Complexity is good – or is it bad?

December 6, 2011

I grew up in a family of engineers.  My father studied electrical engineering in college, but never practiced it because he graduated from college during the Great Depression.  Two of my uncles are engineers, and my older brother preceded me in going to Cornell as an engineering student.

I have always felt that engineering is not only an honorable profession, it also leads to a practical lifestyle that values inquiry, problem-solving and efficient solutions to the challenges in life.  So you may not be surprised to learn that I am a fully qualified lifelong nerd.  I love examining things to discover how they work.  And the more complex the mechanisms, the more interesting they are.

This is where it gets to be a problem.  When I invent something new, like a part of a computer, I revel in the complexity of the thing I’m building.  As long as the complexity serves a purpose, such as actually making the thing do what it’s supposed to do, my brain is tweaked in pleasurable ways when I contemplate the complexity.

If you’ve been reading any of the recent pieces about Steve Jobs, you’ll have understood that part of his brilliance was being able to conceive of simple and easy-to-use products that “just work.”  I worked with Steve in the early days of Apple, and I can verify that it was a challenge being an engineer in a place where the visionary boss kept revising the product based on his latest concept of simple.  Yet even engineers have a principle they repeat to each other to counterbalance their tendency towards complexity – the KISS principle: “Keep it simple, stupid”.

A quote attributed to Einstein says “Make it as simple as possible, but no simpler.”  This teaching admonishes us to simplify our theories, but not so far that they no longer apply to the real world.  Jobs’ vision was to make products that contained complex technology but worked well and intuitively for the common person.  And from that basis, he led the creation of products that have changed the way the world works.

So does this mean that I’m giving up on complex ideas and mechanisms?  Not at all.  The mental contortions I need to undertake to understand complicated things still give me pleasure.  And I believe they keep my mind alive in important ways.  The key to living with such an engineering mind is to keep it from running my life.  I still listen to J.S. Bach’s music with satisfaction at the complexity of the counterpoint and harmonies.  But I also meditate on emptiness to keep the logical brain in check.

The next time you hold a complicated piece of consumer electronics in your hand – such as your mobile phone – take a moment to reflect on its complexity and its simplicity.  Encapsulating one of these in the other is an art.  And to accomplish that encapsulation, you need both engineers and artists.  Long may the engineers and artists work together.

John Levy works with Finance and Operations executives who are sponsors for new IT-based business capabilities.  He helps them to succeed with their projects and to transform their relationship with IT.

Getting business value from every dollar spent in IT is not easy.  You need a guide who is knowledgeable about technology and also speaks the language of business.  John specializes in rapidly getting IT to align with business strategy and to contribute efficiently to the success of the enterprise.

John has been consulting in industry for over 20 years.  His book on management for technology executives, Get Out of the Way, was published in May 2010. 

For more information, please visit https://johnlevyconsulting.com , email him at info@johnlevyconsulting.com , or call 415 663-1818.

 

Filed Under: Painless IT Tagged With: , , , ,

Metrics of Success in Development – Part 3

January 26, 2008

Today we’ll finish the list of ten questions that can give you a quick measure of your development group or department. The purpose is two-fold: to let you see how you measure up compared to other similar departments, and to suggest ways in which you can think about the stresses in your department.

Let’s launch into the final four questions, then we can total them up.

7. Viewed from other departments (outside of Development), how would managers rate your development managers and engineers in each of the following areas?
(a) Cooperativeness (with outside people)
Extremely cooperative – add 3 points
Very cooperative – add 2 points
Cooperative – add 1 point
Uncooperative or unavailable – add 0 points
(b) Flexibility (willing to work with and compromise with others outside the department)
Extremely flexible – add 3 points
Very flexible – add 2 points
Flexible – add 1 point
Inflexible – add 0 points
(c) Team-orientation (beyond the Development department teams)
Extremely team-oriented – add 3 points
Very team-oriented – add 2 points
Team-oriented – add 1 point
Not team-oriented – add 0 points

8. What percentage of the company’s gross revenues in the most recent year were allocated to Development (or R&D)? (If your company has no revenues, or if revenues are less than the Development budget, answer “over 10%”)
(a) over 8% – add 3 points
(b) 4 to 8% – add 2 points
(c) 2 to 4% – add 1 point
(d) less than 2% – add 0 points

9. Comparing this year’s Development budget to last year’s, how did it change?
(a) Increased by 20% or more – add 3 points
(b) Increased by 5 – 20% – add 2 points
(c) Stayed the same or changed by less than 5% – add 1 point
(d) Decreased by more than 5% – add 0 points

10. The number of concurrent development projects now in my department is
(a project is defined as an activity with a timeline and a goal which needs at least 1 full-time person to make progress towards the goal; if you have many small projects, you can count the number of project leaders instead)
(a) over 25 – add 0 points
(b) 15 to 25 – add 1 point
(c) 5 to 15 – add 2 points
(d) 1 to 4 – add 1 point
(e) none – add 0 points


If your total points add up to 52, you have a perfectly-performing development organization and have no need for improvement. For the rest of us, the points are probably in the following ranges:
Excellent: 37 to 52 points
Good: 22 to 36 points
Fair: 13 to 21 points
Poor: 12 points or fewer

How did you do? What does this mean? If you think about the stresses on your department, you can see that the point score is not as significant as the individual issues you’re facing. Are you having a lot of turnover? Slipped schedules? Complaints from other departments about your people? These can all be aggravated by declining budgets which are outside of your control.
Later we’ll examine some of these issues and how you can find ways to work around them. In the mean time, click on the Comment button and let us know how you scored.

Filed Under: Painless IT Tagged With: , , , , , , ,