Should we always pay back Technical Debt?

Jim Highsmith on Technical Debt

A former coworker of mine, Jim Highsmith, has recently written an article on The Financial Implications of Technical Debt. Jim states that recent studies indicate the cost of technical debt is near $1 trillion in the U.S. I would like to see these studies. I do know that not too long ago, Gartner released a report indicating that the worldwide cost of IT Debt will be $1 trillion by 2015. Regardless, the point he makes is still valid - technical debt is egregious.

Jim states, "Unfortunately, by the time many organizations are paying attention, all the solutions are bad ones: 1) do nothing and it gets worse, 2) re-place/re-write the software (expensive, high risk, doesn’t address the root cause problem), or 3) systematically invest in incremental improvement."

Of these three (bad) options, I think the second is often a better choice than the third. The first represents failure to make a necessary decision.

Just chuck it

Let's assume a product has been in development for a few years. During that history, the software delivery team has garnered a significant amount of domain knowledge through trial and error. Some assumptions were validated, others definitively proven incorrect. Adjustments have been made, entire screens have been overhauled to improve the user experience. The data model has been tweaked to accomodate unanticipated requirements without invalidating all prior collected data. And, as we've established, there is significant technical debt.

In this same amount of time, the development tools have undergone three major revision updates, the database platform has undergone one major revision update, and the standards for the web-based front-end have undergone significant change, not to mention the advantages of jQuery, which your app is using sparsly.

The cost of maintenance and new development is on a steep incline. Making reparations as we go along will result in a slow recovery. If it took us four years to get here, it will likely take us four years to recover; perhaps longer. If you've ever worked for a couple of days on a piece of code and lost it, you know it takes about half a day to write the whole thing again and do it better.

So what is more risky? Continuing to work on this code base, cobbling together mis-matched parts in old technologies and slowly grinding out improvements or writing a new one?

I agree good code is an asset. But, just as in other investments, sometimes the best move is to take the loss and get out rather than holding on in hopes of a recovery.

Then do it better

We've the opportunity to advance the tools and technologies. We've an opportunity to build it again fortified with several years of learning through trial and error. Take advantage of this opportunity and do it well.

Training Software Professionals

The Slides

Here is the slide deck to my SCNA talk, "Training Software Professionals, Just What the Doctor Ordered". In the past, my slide decks stood on their own. That is, you could thumb through the deck and easily glean all the key points of the talk. But I am trying to move away from that presentation style to one where the slides offer visual support, but the speaker (me) tells the actual story.

The Story

I am a Software Craftsman

From the moment the phrase was uttered, people starting formulating opinions about what it means. From guilds, exclusionists, and elitism to irresponsibly meticulous artsy-fartsy types to passionate life-long learners.

For me, Software Craftsmanship is trying to live my life in accord with the values. I am not claiming that I live my life entirely in accord with the values. I am saying that I endeavor to do so. Every day. Some days, I do better than others.

We Need To Talk

We need to talk amongst ourselves and with others. We need to talk about what we're doing to actively improve the quality of software. Or more accurately, what we're actively doing to improve the quality of software practitioners, through whom, software is developed and delivered. I don't believe I have the answers. I'm not even certain I have all the right questions. But I am certain that we, as a community, have everything we need to effectively address the issue of quality in our profession.

$1 Trillion by 2015

On September 10, 2010, Gartner Group published a comprehensive study of IT Debt worldwide. The debt is estimated at $500 billion at the end of 2010 with a projection to hit $1 trillion by 2015. Many discussions on software quality meander their way into a debate about the lack of need for rigor when lives are not at stake. Given worldwide IT Debt at $1 trillion, even if only 10 percent of it is from code, we are looking at $100 billion due to poor coding practices. This is somewhere in the range of $14 for each living human. This is more than a complete year's salary for every developer on earth. While we may not be able to draw a straight line from this debt to the loss of human lives, I've no doubt the connection exists.

Our profession is failing to deliver. We must do something.

How do we improve the quality of our code? I suggest we start by improving the quality of our practitioners.

What are others doing?

Many professions have been around for far longer than ours; hundreds of years, even thousands. We may be able to accelerate our learning by observing those who've gone before us. Among the professions actively dealing with the quality of their practitioners, is medicine. This is not to suggest the medical field has yet mastered their shortcomings, but we can still benefit from their progress.
Educating Medical Practitioners
Today's physicians are educated both at school and long after graduation. They begin with a general education followed by a more specific focus on medical science. While this provides them with the science, theory, and philosophy of medicine, it does little to teach them how to apply this learning to the care of people. School is followed by a period of internship or residency where budding physicians learn how to apply their knowledge to the art of caring for people. Physicians are licensed to practice medicine and certified in areas of specialty. They engage in lifelong learning both collaboratively and intentionally on the job as well as through formal (and sometimes informal) continuing education.
  • General / Specialized Medicine
  • Internship / Residency
  • Licensing / Certification
  • Collaborative Learning
  • Continuing Education
Software Development in Contrast
Comparatively, the standard educational process for software developers is a general education with a few classes covering multiple aspects of general technology and perhaps some classes focused on a language or development practices. No residency. Certifications with questionable value. No licensing. Informal self-directed collaborative learning. And no continuing education requirement.

A quick history of Western Medicine

To appreciate where the medical profession is today, it helps to take a look at the events that shaped their profession. This is not a comprehensive review. The medical profession has been around for over 5000 years. In 3000 BC, the egyptians had hospitals, nursing homes, and even medical insurance. Our focus is on Western Medicine with an emphasis on events influencing the course of medical education.
Hippocrates - 400 BC
Hippocrates is often referred to as the Father of Western Medicine. He made many significant contributions to the medical field. Much of what is done today can be traced to the findings and teachings of Hippocrates.

Perhaps most significant of Hippocrates' contributions was the separation of faith and medicine. Prior to Hippocrates, most of what ailed humans was considered to be attributable to deity. But Hippocrates thinking allowed him to look more locally for the source of what ails us.

Hippocrates taught in a Master/Apprentice fashion. He housed a few students and taught them in exchange for which they helped to tend to his land and stock. Students were provided the opportunity to learn, experiment, and eventually practice as he felt they were ready and capable. Students moved on to be practicing physicians and several eventually took on apprentices of their own. Significant priority was given to the proper clinical care and treatment of patients.

The Master/Apprentice format was the prevailing form of education for centuries to follow.
Canon of Medicine - 1025
The Canon of Medicine is a vast collection of medical knowledge from both Eastern and Western cultures spanning several millennia of learning. It was considered, at the time of its writing, to be comprehensive and complete. The canon ushered in a new style of medical learning. With a single text to teach from, Masters could significantly expand their audience and share with hundreds of students at one time rather than a mere few.
Schola Medica Salernitana
Considered the Birth Place of Modern Medical Education, this medical school in Solerno Italy set the example for the next several centuries. Physicians moved away from the Master/Apprentice model to a more scalable and rapid form of education taught in lecture format based on the Canon and supporting texts.

It was generally believed that the texts contained everything possible to know in terms of medical care.
Black Death - 1350
The bubonic plague was devastating. Nearly half of England was killed and over one third of all Europe died. Nothing known about the human body, medicine, surgery, or the cause of illness helped.

Schools focused on finding new ways of identifying and treating human ailments. For the next several hundred years, the medical industry focused intently on scientific discovery and learning.

But as physicians became significantly better at treating disease, they became far less capable at treating their patients. Science had become such a focus, that proper clinical care and treatment of patients was no longer a significant part of the educational process.
Osler and Flexner
In 1904, Sir William Osler wrote a paper urging medical schools to introduce residency as a part of the curriculum. Osler regularly had students accompany him on rounds in the hospital where they learned how to treat people in a clinical setting. He wished to return humanity to the practice of medicine.

Around the same time, the Flexner report was published. The report has a great deal of controversy surrounding it. The funding and execution were questionable, but the impact was significant. The report rated medical schools in the North Americas, identifying those meeting and those failing to meet a set of standards devised by the benefactor of the report. As a result, more than half of the medical schools in the US were closed or lost significant funding.

The remaining medical schools were incapable of meeting the demand while simultaneously implementing residency programs. It was not until the 1960s that residency was common practice for all medical students. As late as the 1980s, some medical licensing still did not have a residency requirement.
As mentioned at the onset, the medical industry now embraces life-long learning with a balanced focus on clinical and non-clinical learning.
  • General / Specialized Medicine
  • Internship / Residency
  • Licensing / Certification
  • Collaborative Learning
  • Continuing Education

Lessons and What Next


Scholastic education is merely the beginning. Knowledge is far more valuable when we know how to apply it. Licensing and Certification can have a positive impact on the level of professionalism. Practitioners share knowledge amongst themselves and create opportunities to learn together. Professionals engage in intentional life-long learning.

What Next

As I said at the onset, I don't believe I have the answers. I'm not even certain I have all the right questions. But I am certain that we, as a community, have everything we need to effectively address the issue of quality in our profession.

We Need To Talk

We need to talk amongst ourselves and with others. We need to talk about what we're doing to actively improve the quality of software. Or more accurately, what we're actively doing to improve the quality of software practitioners, through whom, software is developed and delivered.

But talk should not take too long. Rhetoric may convince many, but will achieve little.

We Need to Act.

Do something. Learn from it. Adjust.
The History of medical education: an international symposium …, Volume 673 By Charles Donald O’Malley, University of California, Los Angeles. Dept. of Medical History
Medical School
Schola Medica Salernitana
Medical Education in the United States
History Medical Education
History of Medicine
A short history of medical education in the United States
The Canon of Medicine
American Medical Education 100 Years after the Flexner Report
The acquisition of skills for practice requires radical transformation. Although the dictum “see one, do one, teach one” may have characterized the way in which clinical skills were learned in the past, it is now clear that for training in skills to be effective, learners at all levels must have the opportunity to compare their performance with a standard and to practice until an acceptable level of proficiency is attained.
- The New England Journal of Medicine, September 28, 2006
William Osler

Uncle Bob on Humility

The following just hit my inbox. It is a post on the Software Craftsmanship Google Group.

On Oct 24, 2010, at 12:36 , David Starr wrote:

My question is, "what can be done to fix the reputation [of elitism] and change the conversation before craftsmanship is deemed irrelevant"?

As a craftsman I am dedicated to improving myself; and therefore I realize I am deficient.  As someone who is admittedly deficient, I am not interested in pointing out someone else's deficiencies.  

In general, whenever someone asks "what can we, as a group, do to ...", the best answer is going to be of the form: "Each of us, as an individual, should ...".  

So, to deal with perceived elitism, each of us as individuals should remember that we are not elite.

Robert C. Martin (Uncle Bob)  | email: uncle*
Object Mentor Inc.            | blog:
                              | web:
                              | twitter: unclebobmartin

Packing Peanuts Game - Variation

Searching for a Game

I was looking for a game that helped to emphasize the detrimental results of a focus on speed over quality. How such an approach had only a short-term gain and then proved to be more costly from there forth.

The Original Game

I don't know if this is really the original version of the Packing Peanuts Game, but it is certainly the first I've found.

The game was posted to tastycupcakes by Masa K Maeda, on May 21st, 2010

Masa identified the game as a way of "understanding what Technical Debt is and why it is so costly to projects." You already know my feelings on calling sloppy code Technical Debt, so I won't go into that here. But it is a decent game for showing that haste does in fact make waste and the only way to truly go fast is to go well.
10 minutes
  • 4 cardboard boxes. Size: around the standard size of a moving box (13”x18”x12”)
  • Enough packing peanuts to fill two of the boxes
  • 2 people
    • You can do this exercise with more people, adding 2 at a time, up to 6 people without the need to have more boxes or packing peanuts 
    • For more than 6 people you’ll need to add more boxes and packing peanuts
  • Set 2 lanes across the room
  • For each lane place one cardboard box (opened for easy access) at each end of the lane.
  • Fill the boxes at the same end of the lanes with packing peanuts: one of them at 70% capacity, and the other one at 90% capacity
  • Each participant will stand next to a box with packing peanuts
Explain the participants their goal: To transfer all the peanuts from the box next to them to the box at the other end of their respective lanes.
  • The person with the 70%-full box is to transfer all of them in three trips and can use hands and arms (and support them on his/her belly if so desired), but nothing else
  • The person with the 90%-full box can take as many trips as desired and can use both hands only
  • The boxes are not to be lifted, tilted, shifted or other. Their sole purpose is to contain the peanuts
  • Peanuts that fall on the floor are left there
  • There is no time limit
  • Do not run and watch your step
  • Start the game
  • Let them play for about 2 minutes or until one of them accomplishes the task
Expected Results:
  • The person with the 90%-full box will finish first or will have transferred more peanuts once the time is up
  • The person with the 70%-full box typically drops way more peanuts to the floor
  • The person with the 70%-full box exerts and stresses more
Learning Points:
The peanuts represent features or aspects of features, and those on the floor represent unfinished work, bugs, etc.
  • One trip represents a release cycle: more peanuts per trip represent a bigger release
  • Big monolithic projects generate more technical debt
  • Big monolithic projects take more energy out of people, and stress them more
  • Trying to bring all features from start to end at once is way more difficult
  • Bringing features to completion in small chunks is easier, and generates less technical debt (less peanuts on the floor)
  • Bringing features to completion in small chunks allows people to work at a better pace and under less stress
  • Bringing features to completion in small chunks results in more features done in less time


This variation of the game is designed to further accentuate the cost of allowing cruft to build up in the code base.
  • Clearly mark the lanes at 24 inches wide.
  • Teams must travel within their lanes.
  • When the game starts, the source box has peanuts and the destination box does not.
  • Fill both source boxes to 90%.
  • Team A is limited to four trips, but can use arms, chest, and stomach to hold as many peanuts as possible.
    • No pouching of clothes or putting peanuts in pockets or up/down clothing.
  • Team B can use as many trips as desired, but can use only hands.
  • When returning to the source box, Team B must collect any previously dropped peanuts and return them to the source box.
  • Team A does not need to pick up dropped peanuts unless they step on them
  • Team A must immediately collect any peanuts they step on
  • Moderators monitor Teams' peanuts and lanes
    • Any peanuts dropped outside of a lane are immediately swept into the lane.
  • Play until either Team A is out of moves or Team B transfers all peanuts, whichever is first.
The idea here is to model what happens in many companies. The team is permitted and even encouraged to go fast and sloppy for some period of time. But the mess eventually impedes the team's ability to move forward at all.

Code as a Cause of Project Failure

The original question

During the speaker panel at SCNA this past weekend, Chad Fowler (@chadfowler) asked, "How many projects fail because of the code?". Given the context, I assumed he was making the point that projects fail due to business issues, not code. The room was silent. While one might have assumed this meant the entire group thought it rhetorical, I concluded everyone agreed with Chad. Projects fail not due to code, but due to business issues.

The follow-up

Uncle Bob (@unclebobmartin) later did a quick twitter survey, which I and many others took part in. The results were overwhelmingly in favor of project failure being more attributable to business issues than technical issues. Bob felt many might take this to mean that code is not all that important in the long run and that craftsmanship, therefor, is not all that important either. Bob put together a well thought-out argument explaining why code is important and how it can, in fact, kill not only a project, but entire companies. Rather than reiterate it here, I strongly encourage you to read Bob's article, "The Cost of Code?" I agree with most of what Bob says in this article. The Cost of Code is high. I don't agree that all failed projects are due to code, but his points in support of that statement are no less valid.

Cause versus Responsibility

Smoking Guns

A man lays dead; a single bullet wound in his chest. A project fails; a mass of crappy code remains. Perhaps it is clear to you that a bullet killed the man. Perhaps it is clear to you that crappy code killed the project. Rather than enumerating other possible conclusions, given our substantial lack of evidence, I will conceded both points. The man was killed by a single bullet and the project was killed by crappy code.

Yes, technically, the project failed due to code.

Trigger Men

Our tragedies do not end there. We can no more stop murder by eliminating bullets than we can save projects by eliminating the need for code. While the bullet or the code may be the cause, they are both effects as well.

Somebody pulled the trigger.

In large projects, identifying one guilty party is commonly impossible not to mention grossly naive. In large projects, there are typically many humans responsible for the failure. If we were to perform archeological studies on the ruins of most projects, I am confident we'd find the failure to be between people. I am confident we would find it was a failure of communication. Not one, but hundreds or even thousands of failures; large and small. Lack of vision. Lack of clarity. Lack of cohesion due to lack of vision and clarity. Lack of clear expectations. Unclear status. Keeping quiet when we disagree. Raising disagreements in a non-constructive manner. Approaching debate as if it were battle. Inflammatory language that creates divides. Hiding our mistakes. Sending an email instead of making a phone call. Making a phone call instead of meeting face to face. Too much emphasis on delivery. Thinking speed and quality are diametrically opposed. Undervaluing the work of others. Apathy. The list goes on.

On a software project, code is critical. You can't have a software project without code. The worse the code, the greater the risk to the project. Bad enough and the project will fail as a result of the code. Significant enough, and the company will fail as a result of the project.

But don't forget it is we who write the code.

It is we who pull the trigger.

On The Scrum Compliance

A recent article by Tobias Mayer has been getting a lot of attention. "The Scrum Compliance" is an accounting of why Tobias is moving on from the Scrum Alliance. This article is not the first on the ugliness that has become the Scrum Alliance.

I've read this article a number of times and I am disheartened by all of this. Such an ugly series of events playing out in an opaque manner on a semi-public stage. We hear pieces of what has transpired and assumptions about what motivates the participants. We get facts mixed with opinion mixed with emotion. The "logical" conclusions, when seriously considered are not logical. That the committee representing the Scrum Alliance is comprised of power-greedy oligarchs does not at all seem like a logical conclusion. Yet, I hear it stated as if it is known fact based on the "evidence".

I'm neither defending nor attacking anyone here. I think Tobias is an honorable man who speaks from the heart. I am not saying that he is right or that he is wrong. I am saying I do not know, that very few of us actually does, and that he alone cannot tell the entire story.

Regardless, I now question my connections with the Scrum Alliance. They are not particularly tight, but whether I believe the rumors or not, it seems a good time to be a distance from the SA rather than standing next to it, taking shrapnel.

Esther Derby asks: Are we aiming too low?

Esther Derby's Post

Esther Derby put together a nice post on the importance of design for a web site in which she asks, "Are we aiming too low?"

Agile methods manage business risk. They can bring back enjoyment and pride in work for development teams. For the people who use our software, they make work life maybe less frustrating, because the software isn’t buggy, and maybe a little easier because the software does what it’s supposed to do. But I think we are aiming too low. Can we also make software a pleasure to use?

Makes me wonder

Story Composition

I've been working with teams lately on story composition. We've been discussing how we could break stories down based on value to the business rather than based on how we technically execute. Our objective is to be able to deliver value to the business as quickly as possible. So we want to avoid chunking larger stories out into smaller stories that are then dependent upon one another for delivery. We've really achieved nothing other than creating bottlenecks in our flow. We still have to build the whole thing in order to deliver.

So a common technique we've been using is to break out aspects of the story that are must have from nice to have. Often, this ends up being along the seam between functional and sexy. With functional clearly being must and sexy riding shotgun at best.

Executing on this strategy, we are able to deliver functionality faster and we haven't any dependencies between the stories other than the must have need to come first. But this is perfectly acceptable to the team. Must have should come first.

Are we missing something important?

I think we are. I think by consistently breaking the stories down in this manner, we are cheating the customer. We keep putting features that make the application nice to use on the back burner. Frequently they don't get implemented because the next "must haves" bubble to the top of the queue as the "nice to haves" slowly drop.

But by executing in this manner, we are consistently missing the opportunity to make the user experience truly pleasurable. We are focusing too much on utility and not enough on what makes the application truly desirable.

Technical Debt versus Cruft

Am I Tilting at Windmills?

I repeatedly find myself in discussions with really smart and experienced people regarding Technical Debt. And I consistently find myself ranting about how cruft and technical debt are not the same thing. I am beginning to feel I am merely tilting at windmills.

I don't know if my prior rants on the topic of Technical Debt have provided sufficient clarity. In them, I try to better define Technical Debt and point out the differences between it and cruft. But I do not provide any tangible examples. Herein, I attempt to remedy that situation. Today's installment is in narrative form. I intend to provide a later post with code examples.

Technical Debt - A brief reprise

Ward Cunningham coined the phrase Technical Debt
"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise."
As he clarifies later in a You-Tube video, Ward was specifically talking about design decisions made in the course of developing software that allowed for more rapid delivery. Rapid delivery not for the sake of meeting a deadline. Rapid delivery to illicit quick feedback, thereby providing the data necessary to adjust the design to be more congruent with actual needs. The object design should change to reflect your current understanding of the domain, even if that understanding is partial. Technical debt is payed back through code refactoring as our understanding of the domain matures.

Ward clearly states, "The ability to pay back debt [...] depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem."

Clean Code is actually a prerequisite for Technical Debt. If you don't have Clean Code, you cannot expect to pay the debt back. If you have cruft, you cannot reasonably incur Technical Debt. In fact, you are not incurring debt, you are merely adding to the existing mess.

Examples (in Narrative Form)

Technical Debt

Example One
We are building a new application to allow our customer to sell widgets and parts to distributors.
  • Widgets represent 75% of the sales.
  • 82% of the customers order on terms.
  • The cross-section of these two groups represents 69% of all sales.
In order to get the application running and generating revenue, we decide to launch with only widgets and terms. We will sell parts later. We will also add other forms of payment later.

This is a strategic decision. We are creating a design that we know will have to change. We know we will re-visit this code and perhaps even throw away some (or much) of it.

But we write it well, we test drive it, and we do not compromise quality. We will defer to the last responsible moment and make the design adjustments based on what the business determines is the next highest value activity when it is decided.
Example Two
We are working with a third party API for determination of flood plane coverage for a given property. We want to know this so we can decide if we will or will not provide an applicant a loan. We don't give loans on properties in flood planes.

We can make numerous calls to the service. One, which is simple, will tell us if the property is in a flood plane or not. This is all we need to know for an accept or reject call.

We decide to go ahead with this basic functionality and make sure the service is consistently reliable in terms of uptime, speed, and accuracy. We are going to run one server against the new service and leave the others running against the old (slow and more expensive) service.

Once we've determined the service provider is reliable, we will also code the pieces for garnering more specific data. It would be good to have this on the loan application record if there are any questions in the future, but it is not mandatory.

This is a strategic decision. We are creating a design that we know will be either eliminated or expanded.

We write all of the code well. We test drive it. After a period of learning, we will either toss the code or we will add new features.


We are working on a system to schedule production of widgets on the factory floor.

We have a bonus initiative to get the application done by the end of the year. It is September and we're just getting started due to delays in the delivery of our prior project. According to the schedule, we should have started in May. If we miss the deadline, there will be much gnashing of teeth. If we miss the deadline, we will not get our bonus. We ask our boss if we can deliver only part of the application, but her bonus is much more significant and requires complete delivery. She denies the request, admonishes us for putting her in this situation, and reiterates the priority of this project for "the business". She let's us know that the CEO is watching this one. The CEO was watching the last project too. That's how important IT is to the corporate strategy.

So we work like crazy. We skip unit testing. We work in silos and make decisions on the fly about ambiguous requirements. We notice the FillQueue class is getting quite large and everything is dependent on it. But we don't have time to change it. It works and we are under pressure to deliver. Besides, we could no longer test these classes in isolation if we wanted to. We'd have to tease them apart at the seams and that could take weeks. It is getting more and more difficult to write the code. It is like a bowl of gelatin; you touch it down here and it wiggles up there? Why does it do that? Whatever. We need to make the deadline.

This is the wrong decision for the business. This is not a strategic initiative. This is not professional or even ethical behavior. This is a failure.

But bonuses got paid.

What about you?

I've been told delivery teams don't take on Technical Debt as a strategic initiative, rather most produce cruft and then call it Technical Debt. Help me prove otherwise. Please post a comment with an example of Technical Debt (not Cruft) taken on by a team you worked on.

Values Revisited


In 1992, I started a custom software development company out of my basement. I started it because I was angry. At a relatively young age, I was already keenly aware of the gross dysfunction that existed in most organizations. I didn't want to be a part of that. I wanted to be a part of something different; something better. I had no plan, but I had an abundance of temerity.

Our progression over the years was adventurous, romantic, and stupid. Moving into our first real office. Housing my partner in my basement. Running out of gas on the way back from a critical meeting because we didn't have enough cash to fill the tank. The victories. The losses. The camaraderie. The angst among us.

By 1997, we were close to 20 people. Tiny, yes, but I felt it was too big for me to handle at the time. I was 29 years old with no formal education and limited "real-world" experience. My penchant for self doubt was getting the better of me; temerity had been replaced by timidity.

In a moment of melancholy and introspection, I sat down and drafted the following. It was my intention to express a core set of values to the employees of my fledgling company. And I do suppose it served that purpose. But it was the first time I had committed to paper the things I was looking for in a company. Perhaps the things I was looking for in life.

Our Values...

... are the foundation for all decisions. They serve as the compass that guides us through our personal and professional lives. All action; all thought; in every way we represent ourselves; we must represent our values.

Be fair.

Find the answer that best serves all parties. Act upon your highest sense of right.


Grow continuously, personally and professionally, in small ways. Evolution is the sum of many tiny, nearly indiscernible adjustments.


Seek new ways; seek new means; do the unexpected.

Take Initiative.

Present your ideas. Put forth the extra effort. The one who makes the most mistakes, learns the most lessons.

Be accountable.

Answer for your mistakes and your deserved praise will come.

Be forgiving.

Seek to understand and assist. Do not condemn others for their differences. To criticize and dismiss leaves neither party better off.


Become truly involved. Make this your team, for it already is.

Have respect.

Honor your coworkers and clients.


Make your life rich in many ways. Seek new experiences, new relationships, and a new perspective. Then bring it back and teach others.

And always, Tell The Truth.

- Michael J. Norton (1997)


In 2001, we closed the company. The values statement had been posted on my wall for several years. It had become invisible. Sitting in the same place year after year, it was no different than the pencil holder on my desk. I could look in the general direction and not consciously recognize it was there. Only when I specifically sought it out did I truly see it. And I had stopped seeking it out.

By the time we officially closed the company, I had returned to corporate America, seeking knowledge, wealth, and (most of all) security. As I noted, temerity had long since given way to timidity.

For several years, I climbed the ladder making my way to CTO. I kept the values statement in my day planner. But it was still invisible. I did not seek it out. And when I stumbled upon it, I glanced and moved on. I felt that most around me were living by a different set of values and that perhaps I was too naive and idealistic.

In 2009, I was let go. I should have resigned of my own will, but I was too much a coward, so they provided me the opportunity.

I was feeling melancholy and introspective and for the first time in nearly a decade, I looked at my values statement again. I mean really looked at it.

And I changed my life.


I am a partner in a firm that is consistent with my values. I do work that allows me to share these values with others in indirect ways. I surround myself with people who represent who and what I wish to be.

And I make sure that I take the statement out every so often and look at it. I mean really look at it. Melancholy not required.