From the Wilder Archives

Interview was conducted on May 29th and recorded in the lobby of the Courtyard hotel. The write up was done at Starbucks in the Presidio, San Francisco, California.

Unlike my other interviews, this was the first one that I conducted in person instead of via a phone conversation. It felt fitting that I was recording it on my iPhone because I was talking to Ron Lichty, who was one of the early product managers for Apple’s development tools. Even though Ron trained as an engineer, he has often found himself managing people vs. writing code. For three of his eight years at Apple, he managed the company’s “secret jewels” – the UI and code for Macintosh Finder.

After Apple, he worked at Berkeley Systems, which was one of Silicon Valley’s early consumer software success stories. In the early 1990s, Berkeley Systems had many successes, such as was After Dark,* a modular screen saver that included flying toasters, and the trivia game You Don’t Know Jack. Later on, Ron worked at Fujitsu and then at Schwabwhere he managed the team that wrote the first investor tools in Java for Schwab.com. It is because of those early experiences in product management that I wanted to interview Ron. He has managed engineers, and he has been an engineer himself for just over three decades. He has seen high technology product management evolve since the 1980s.

Ron has spent most of his time untangling software – “the knots” that can impact, complicate, and delay software development. That’s what led him to partner with Mickey Mantle (not of the Yankees) to write Managing The Unmanageable, which is due out this fall. The book focuses on how to be successful in software development, whether it’s IT or whether it’s a product or service. Their book is actually a culmination of their breakfast meeting discussions about the “rules of thumb” and “nuggets” of insights  about software development that they have shared over the years.

An example of this wisdom was Fred Brooks’ classic statement in the The Mythical Man Month,“adding manpower to a late software project (just) makes it later.” Notwithstanding these classic books on managing projects, Lichty and Mantle observed there was a lack of books on managing programmers and managing programming teams.

Together Lichty and Mantle have managed programmers for over 60 years.  Their first key point in the book is that programming is not engineering. Programming does, however, have some aspects of engineering but so does many a craft as they mention in their upcoming book:

“Since 1968 attempts have been made to apply the term “software engineering” to the art of programming. But writing a new program from scratch is much more akin to writing a novel than to the established practices of civil or electrical engineering. New programs frequently begin with a “blank sheet of paper”, whereas engineering projects are typically assembled from libraries of components and rigorous codes of acceptability. Software engineering (or programming as they refer to it in their book) continues to be more of a craft than a rigidly defined engineering discipline.”
There was a good article in the September 1994 issue of Scientific America entitled Software’s Chronic Crisis,  which recounts the attempt in 1968, on the 25th anniversary of programming, to remake programming as engineering by superimposing the term “software engineering”
 “The art of programming has taken 50 years of continual refinement to reach this stage. By the time it reached 25, the difficulties of building big software loomed so large that in the autumn of 1968 the NATO Science Committee convened some 50 top programmers, computer scientists and captains of industry to plot a course out of what had come to be known as teh software crisis. Although the experts could not develop a road map to guide the industry toward firmer ground, they did coin a name for that distant goal: software engineering, now defined formally as ‘the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software……A quarter of a century later software engineering remains a term of aspiration. The vast majority of computer code is still handcrafted from raw programming languages by artisans using techniques they neither measure nor are able to repeat consistently.” (September 1994 Scientific American article Software’s Chronic Crisis)  

“Programmers are craftspeople and not engineers, who focus on building the same thing over and over again.”   What it takes to be a good programmer is the combination of both an engineering and a craftsperson way of thinking. It is to be able to pull order out of chaos in your mind. In listening to Lichty, I got the impression that he thinks programmers don’t get enough respect. In Silicon Valley, I think that has changed. Now, programmers rule in companies. However it is clear that this is not the case in other organizations around the country.

What it takes to be a good programmer is a combination of the mind of an engineer and the mind of a craftsperson—of being able to pull order out of chaos in your mind.  One of the things you see in programmers is that a whole lot of really good programmers are also musicians, and the mentality that it takes to be a musician is similar to the mentality that it takes to be a programmer.  I don’t think you see that as the same across-the-board – the connection between musician and any other kind of engineering.  It’s because it’s a craft, not just engineering.  So, why is it harder?  It is because we keep building bigger, greater, and heavier-duty things. We keep improving our processes, but they don’t keep up.

Ron summarizes this up  with “strong developers are doing software development because they want to make a difference in the world.”

When starting a new company, Ron advises companies to first hire a VP of engineering, somebody who understands that managing programming organizations does not mean micro-managing your team.

“It is not managing down.  Instead, you need to think about turning your organization upside-down, and that the VP of engineering is supporting – it’s not the pyramid from the top; it’s the pyramid from the bottom.  The VP of engineering is supporting his directors—his or her directors—and the directors are supporting their managers, and they’re supporting their teams.  And you’re trying to create teams that are self-motivated, self-running, self-aware, highly collaborative, and transcend the – just the individual skills of the individuals, to work so well together that they do something that’s greater than any – than you would think, just adding them together.”

Ron stresses the importance of companies sharing their vision and their product’s raison d’être (reason for being) with their front-line programmers. Developers want to know how their contribution will make a difference. I have experienced this first-hand because many IT or engineering organizations around the country fail to share their road map with their employees. So, Engineering has to partner closely with product management, who usually sets the vision for the product.

“It divides products into minimal marketable features and says, how are we going to do all the stuff we want to do, and then make a list of all the things that make a difference to customers.  Then you can do an ROI or Net Present Value on them (each feature). We can look at the difference of releasing a product in two months vs. eight months vs. 16 months. So one question is can we beat the competition We need to be able to do those kinds of discussions. You need to be able to examine the issue from a product side.  It’s one of the product management responsibilities to map out the competition and map out the product, and understand where the value lies.”

When designing and developing a product, both ROI and net present value need to be calculated so teams can understand the impact of what a particular feature will have to customers. Of course, this is easier said than done. Many companies don’t try and figure out the economics of a feature or a change to the code. To help with this, Ron recommends Software by Numbers: Low-Risk, High-Return Development by Mark Denne and Jane-Cleland-Huang. It provides an analytical framework on the product side. That’s a match for the analytical framework that needs to be done on the engineering side.

Ron wanted to make sure people understood the importance of ‘making an important impact on the world’ while measuring ROI and NetPresent Value.
When Chuck Schwab talked about not wanting to see people reach retirement and be living in YMCA rooms for lack of planning – he touched and inspired the developers who were working on Retirement Planners and Asset Allocation tools and trading software. They had a “reason” – they could see how what they were doing made a difference. Steve Jobs talked about Changing the World and everyone at Apple bought into that vision, even after Steve had been fired by Sculley.
NPV and ROI are critical on the product and finance side. What they do for programmers is provide an analytical framework to show what features the market cares most about – which means what programmers are working on will make the most difference to customers. IMHO (which is Internet slang for ‘in my humble opinion’), revenue and profit are side effects of delivering value to customers. Developers care about delivering value to customers – making a difference.

Or, as Lichty and Mantle state in their book:

It is the rare individual who does not want to make a difference in the world. Many if not most of us chose to program at least in part for the opportunity to positively impact the world we live in. If your organization is building or providing something that can be pitched as making a contribution—improving the world in some way—you will have an easier time recruiting and motivating your staff. People are always willing to work harder and longer when they feel their efforts matter.—-Chapter 7, Motivating Programmers

Our conversation then focused  on Agile, which is a popular topic in product amongst development circles these days. Ron pointed out that Agile is more of a philosophy. It is a term that often gets applied to a whole set of approaches to software development, especially in the ’90s, when the “gurus” of all of those approaches got together and said, “You know, we’ve got more in common than we have different.”  Where this commonality comes together is under the Agile philosophy. There’s an Agile Manifesto, which has a set of principles and four key components:

  1. Individuals’ interactions over processes and tools.
  2.  Working software over comprehensive documentation.
  3.  Customer collaboration over contract negotiation.
  4.  Responding to change over following a plan.

Having good documentation in an Agile or Lean environment is less important than the actual conversation between the product visionary and the other members of the team.This discussion is known as a scrum. One the main themes is “tear down the wall between groups.” The thinking is that if everyone is in the same room, looking at each other in the eye, there will be less misinterpretation.  Another of the main themes is frequent “releases” in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.

As a result, writing a 400 page docs, something I was guilty of at Intuit, until Seth Webster schooled me in Agile in 2007, is loosing its supporters. Those kinds of War and Peace length requirement decks only lead to a 20% completion of requirements.

Ron covered four different areas of agile:

  • Scrum, which many people think of as a framework: it represents a radically new approach for planning and managing projects, bringing decision-making authority to the level of operation properties and certainties.
  • Extreme Programming, which was developed by Kent Beck, advocates a set of engineering practices like programmers working in “pairs” (two programmers, one monitor/one keyboard, which tends to increase quality earlier and increase throughput over the course of a project by decreasing rework) and “test driven development” (writing tests before writing code, which helps to ensure the feature is first understood and increases quality).
  • Lean which is based on a set of principles:
    1. Eliminate waste
    2. Amplify learning
    3. Decide as late as possible
    4. Deliver as fast as possible
    5. Empower the team
    6. Build integrity in: The customer needs to have an overall experience of the System – this is the so called perceived integrity: how it is being advertised, delivered, deployed, accessed, how intuitive its use is, price and how well it solves problems.
    7. See the whole— software is the sum of its interactions;  Defects in software tend to accumulate during the development process – by decomposing the big tasks into smaller tasks, and by standardizing different stages of development, the root causes of defects should be found and eliminated. The larger the system, the more organizations that are involved in its development and the more parts are developed by different teams, the greater the importance of having well defined relationships between different vendors, in order to produce a system with smoothly interacting components. During a longer period of development, a stronger subcontractor network is far more beneficial than short-term profit optimizing, which does not enable win-win relationships
  • Kanban: It is a scheduling system that helps determine what to produce, when to produce it, and how much to produce.

(some of the above content came from Wikipedia)

Ron mentioned that Lean leverages heavily W. Edwards Demings manufacturing process. (By the way, Deming, regarded as having had more impact upon Japanese manufacturing and business than any other individual not of Japanese heritage) was my professor at  The Leonard Stern School of Business at New York University in 1989. At 90 something his body was slowly giving out, but his mind was as sharp as ever. I remember him waddling up to the blackboard – yes, we had them back then — and accidentally bumping an elbow into the light switch and turning the lights off. Within seconds, one of the many PhD candidats who followed him, turned them back on. He was a rock star back then; many of the Japanese students would line up after each class for his autograph.)

Ron provides a simplified plan of action for scrum:

  1. Decide on the length of sprints (typically 1-4 weeks) – which should for the length of the project remain fixed so that throughput (in Scrum, called “velocity”) can be measured and then predicted
  2. Get the product manager to list all features and tasks associated with that; each should be able to fit on a 3*5 index card
  3. Then ask them to prioritize these features and be clear about which features you want to deliver and why
  4. Then the team and the product owner jointly decide which ones you want to deliver in the next sprint (duration of time which could be 3 weeks)  and which the team feels it can commit to delivering
  5. Less documentation and more collaboration are key: only at this stage are features and tasks – those going into just this sprint – elaborated fully
  6. At the end of each sprint, the team 1) demonstrates and delivers a working product (features to that point) and 2) looks at how it could work better to make the next sprint even more productive

For more detailed information about scrum methodology.

One issue I brought up during our conversation is the conflict between a Guiles approach of having everyone in one room vs. the current trend of having dispersed teams. According to Ron, these have been two conflicting themes in the last decade. Some people quoted in Lichty’s book discuss the level of value of having people within eyesight of each other, and that there is no way that a distributed team can be as productive as a team that’s got eyesight contact.  They just can’t.

Ron believes over half the development in this country leverages some flavor of Agile. According to the report below, he is correct

Source: Version One. For the full-report.

An Agile initiative often starts at the grass roots level. When I was at Intuit and eToys, Agile started at the group leader and programmer levels of the organization. Several younger engineers convinced their business owners and product managers to orchestrate the team with the Agile method. Eventually it caught on not only to other parts of IT but also other parts of the organization such as marketing. One of the trends that has accelerated the adoption is the ability to update software in real time, whether it is something as simple as a blog to something more complex as a satellite. Even coke machines order inventory real time via modem these days.

When asked about how ROI applies to Agile, Ron mentioned a term I had never heard before “Technical Debt.”*** Technical debt has lots of sources, but one example is writing crufty  code** to just get the product out. You’ve got something to put in, and you’ve got no time left to do it. You Band-Aid the thing together in order to get it out the door.  That’s technical debt. If you let technical debt build up, it’s just like the financial model.  If you allow debt to build up, you’ve got a higher and higher debt that you’ve got to pay back.  And at some point, you won’t get any development done until you’ve paid down your debt. Similar to financial debt, however, if you keep printing more money or keep adding more band-aids, there will come a time when you have to pay back the system and fix your code.

It was great talking to Ron again. He is one of the few practitioners who have been in the trenches and practiced the art of agile development. He successfully helps untangle organizational knots, creates roadmaps everyone can follow, builds communications with other parts of the organization, coaches and trains organizations in agile and scrum, and gets teams productive and focused on delivery, quality and customers.

As I alluded above, Agile has gone beyond the engineering group and into product management. Unfortunately, that’s more or less as far as it’s gone. Business line leaders have not leveraged it yet, so this could be a key trend or transformation that will take place in organizations. Certainly books, such as Eric Reis, Lean Start Up will accelerate this. Although he still focuses more on engineering and products design, his method advocates creation of rapid prototypes that test market assumptions, and uses customer feedback in an effort to evolve the design faster than more traditional product development practices, such as the Waterfall model.  It is not uncommon to see Agile development teams in Lean Startups release new code to production multiple times a day or a week.

Business leaders need to be more nimble and think in terms of continuous just-in-time improvement. In the process, their development and deployment cycle will continue to get better and better by focusing consistently on where’s the waste, and how do we eliminate the waste. Even a functional area as tactical as Quality Assurance could benefit, because historically they have developed testing docs based on the content in a requirement doc. Imagine if they didn’t have to read a 400 page document, three-fourths of which will never be developed.

All of this could lead to a cultural transformation in a company. The challenge is that while many companies are adopting the agile approach, senior management still operates under a command and control paradigm. It’s usually the founder or the CEO that impact a company’s culture, not a development or engineering team.

After Dark was the first multi-screen saver – the first screen saver that let you “change the channel”

** When Ron used the term Crufty, I thought he had made it up, but it actually is a term. According to Wikipedia Crufty is jargon for software or hardware that is of poor quality. The term originates from source code that is rewritten leaving irrelevant or unwanted data within the code.

***Ward Cunningham invented the term: Technical Debt. Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.

Common causes of technical debt include (a combination of):

  • Business pressures, where the business considers getting something released sooner before all of the necessary changes are complete, builds up technical debt comprising those uncompleted changes
  • Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications
  • Lack of building loosely coupled components, where functions are hard-coded; when business needs change, the software is inflexible.
  • Lack of test suite, which encourages quick and less risky band-aids to fix bugs.
  • Lack of documentation, where code is created without necessary supporting documentation. That work to create the supporting documentation represents a debt that must be paid before the code can be considered maintainable by other developers.
  • Parallel Development at the same time on two or more branches can cause the build up of technical debt because of the work that will eventually be required to merge the changes into a single source base. The more changes that are done in isolation, the more debt that is piled up.
  • Delayed Refactoring. As the requirements for a project evolve, it may become clear that parts of the code have gotten unwieldy and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is written to use the current form, the more debt that piles up that must be paid at the time the refactoring is finally done.
  • Laziness. Lack of commitment from the people involved.
Source: Wikipedia
Related Links:

Thank you Nation!

Transcripts are created on a rush deadline, so the accuracy and availability may vary. This text may not be in its final form and may be updated or revised in the future. Please be aware that the authoritative record of Wildervoice’s programming is the audi