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…

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]

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.

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.

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.

In search of a good book on Chef itself, I picked up this new title on O’Reilly. It’s one of their new format books, small in size, only 75 pages.

There was some very good material in this book. Mr. Nelson-Smith’s writing style is good, readable, and informative. The discussion of risks of infrastructure as code was instructive. With the advent of APIs to build out virtual data centers, the idea of automating every aspect of systems administration, and building infrastructure itself as code is a new one. So an honest discussion of the risks of such an approach is bold and much needed. I also liked the introduction to Chef itself, and the discussion of installation.

Devops is one of those fancy contractions that tech folks just love. One part development or developer, and another part operations. It imagines a blissful marriage where the team that develops software and builds features that fit the business, works closely and in concert with an operations and datacenter team that thinks more like developers themselves.

In the long tradition of technology companies, two separate cultures comprise these two roles. Developers, focused on development languages, libraries, and functionality that match the business requirements keep their gaze firmly in that direction. The servers, network and resources those components of software are consuming are left for the ops teams to think about.

So too, ops teams are squarely focused on uptime, resource consumption, performance, availability, and always-on. They will be the ones worken up at 4am if something goes down, and are thus sensitive to version changes, unplanned or unmanaged deployments, and resource heavy or resource wasteful code and technologies.

Lastly there are the QA teams tasked with quality assurance, testing, and making sure the ongoing dearth of features don’t break anything previously working or introduce new show stoppers.

Devops is a new and I think growing area where the three teams work more closely together. But devops also speaks to the emerging area of cloud deployments, where servers can be provisioned with command line api calls, and completely scripted. In this new world, infrastructure components all become components in software, and thus infrastructure itself, long the domain of manual processes, and labor intensive tasks becomes repeatable, and amenable to the techniques of good software development. Suddenly version control, configuration management, and agile development methodologies can be applied to operations, bringing a whole new level of professionalism to deployments.