Understand the High Cost of Technical Debt by Ward Cunningham (Video)

A week or two ago, I got into a conversation on Twitter about technical debt, and someone shared this superb video by Ward Cunningham (youtube). Here is Ward’s Interview website.

Join 10,000 others and follow Sean Hull on twitter @hullsean.

Waterfall, agile, developer or operations, devops, managers, CTOs… everyone should watch this video, for it cuts to the heart of the challenges we face doing modern software development, in a fast paced and always changing environment.

Though it’s not mentioned in the video, I would argue using an ORM is an expensive form of debt, one that is improperly calculated by teams, managers & startups, and one that bites hard into future scalability. Stay tuned for a post about that!

Enough said, here’s the video.

Here’s the transcript of much of the dialog. Appologies for any typos…

1. Metaphors & Thinking

I became interested in the way metaphors influence the way we think

after reading George Lakoff & Mark Johnson’s Metaphors We Live By (Amazon).

An important idea is that we reason by analogy through the metaphors that have entered our language.

Related: 5 Things Toxic to Scalability.

2. Coining Debt Metaphor

I coined the debt metaphor to explain the refactoring we were doing on a product.

This was an early product done in smalltalk. It was important to me that we accumulate the learnings we did about the application by modifying the program to look as if we had known what we were doing all along. And to look as if it had been easy to do in smalltalk.

The explanation I gave to my boss, and this was financial software, was a financial analogy I called the debt metaphor and that said that:

[quote]
If we failed to make our program align with what we then understood to be the proper way to think about our fin objects, then we were going to continue to stumble on that disagreement which is like paying interest on a loan. -Ward Cunningham
[/quote]

Also: AirBNB didn’t have to fail when Amazon went down.

3. Need for Speed

With borrowed money you can do something sooner than you might otherwise, but until you pay back that money you will pay interest.

I thought borrowing money was a good idea. I thought that rushing software out the door to get some experience with it was a good idea. But that of course you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

Read this: Why generalists are better at scaling the web.

4. Understand the Burden

I think that there were plenty of cases where people would rush things soft out the door & learn things, but never put that learning back into the program. That by analogy was borrowing money thinking you never had to pay it back. of course If you do that you know say with your credit card, evemtually all your income goes to interest & your purchasing power goes to zero.

By the same token if you dev a program for a long period of time, by only adding features, and never reorganizing it to reflect your understanding of those features, then eventually that program does not contain any understanding and all efforts to work on it take longer and longer. In other words the interest is total. You’ll make zero progress.

Check out: How to hire a developer that doesn’t suck.

5. Achieving Agility

a lot of bloggers at least have explained the debt metaphor and confused it i think with the idea that you could write code poorly with the intention of doing a good job later. and thinking that that was the pirmary source of deb.t I’m never in favor of writing code poorly. But I am in favor of writing a code to reflect your current understanding of a problem even if your understanding is partial.

If you want to be able to go into debt that way by dev soft you odn’t completely understand, you’re wise to make that software reflect your understanding as best you can. So that when it does come tiem to refactor it’s clear what your thinking was when you wrote it. and making it easier to refactor it to what your thinking is now.

in other words the whole debt metaphor or lets say the ability to pay back debt, and make the debt metaphor work for your advantage depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.

i think that’s a good methodology it’s at the heart of extreme programming. the debt metaphor is an explanation, one of many explanations as to why extreme programming works.

Read our popular interview guides for candidates, managers & recruiters: MySQL DBAAWS Expert (Amazon Cloud) and Cloud Deployment & Automation Engineer.

Don’t forget, hiring is a numbers game

Get some in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample

5 Reasons Devops Should Blog

Join 9500 others and follow Sean Hull on twitter @hullsean.

1. Stand up and be heard

Years ago I was sitting on an online forum chatting with an Oracle buddy of mine. This was circa 1998. We were working on an open source tool to interface with Oracle. There were all these libraries, for PHP & Perl, and a lot of developers starting to build tools. We hatched this hair brained idea to write a book about all of this, and pitched it to O’Reilly. They loved it and thus was born the book Oracle & Open Source in 2001.

Writing a book was, is and always will be a lot of work. It was a great learning experience too. Editors critique your writing, and this teaches you to speak to a broader audience, clarify your statements, and including illustrations and stories.

Along with this came opportunities to speak at conferences, user groups and meetups. It’s exhilerating, and professionally challenging, and I enjoyed all of it.

Blogging allows you to do all of the above in a more measured way. Write regularly, get your ideas out there, get feedback, rinse & repeat. What’s more over time you’ll build up a library of material some of which will draw solid, strong, repeat traffic. It may be what you are most passionate about, what ideas you’ve ironed out smoothly, or what material is most missing from the we already. Whatever the reason your analytics will show you the way.

Read this: Database expert interview questions for candidates, recruiters & managers

2. Share your lessons

In professional services engagements, you learn something new everyday. After a few years you’ll have some battle scars & war stories too. For example I used to have a strong distrust of sales. But through real lessons in the feast or famine world of running your own business, you learn some survival instincts. And knowing how to sell your services & expertise is an art all to itself.

Also: A CTO Must Never Do This

[quote]
Getting up and taking a stand isn’t easy. You’ll receive criticism, and likely feel professionally vulnerable at first. But that only makes us stronger engineers, willing to listen, and better communicators.
[/quote]

3. Get opinionated

Taking a stand on controversial topics, is it something you want to do? Is it something you can do confidently, but also being open to criticism, and seeing all sides.

It’s challenging, but in that process it will either open you to new ideas, or make your resolve stronger. And that process is great for your professional development.

Also check out: AirBNB didn’t have to fail – don’t go down with Amazon

4. Withstand a sh*tstorm

Audiences keep you honest. If I were to go out on a limb I’d say technically brilliant, engineering audiences even more so.

I remember a post I did a year ago, which referenced a feature based on a wrong software version. In other words that feature would not work based on my article. The readers tore me to pieces in the comments.

But listen closely now, I’m saying that’s a good thing. Yes criticism is a very good thing indeed. Get enough of it, and you’ll learn to weed out the folks who are just trolls, from the ones with genuine suggestions. And all that makes you stronger!

Learn to listen a bit, and that makes you an even better sysadmin or devop.

Related: 5 conversational ways to evaluate great consultants

5. Learn by doing

Developers, ops, DBAs and Big Data jockeys alike are doers. We sit and code, build & configure components, troubleshoot & tune. Writing is descriptive and often it’s difficult for us to step back and describe what we’re doing.

By writing we carefully sift through our own thought processes to break it down for novices, or a broader audience. This is a learning process for us too. It’s therapeutic. But also it hones our message and makes us better teachers. We literally learn by doing.

Also: The Myth of Five Nines

Get some in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample