Continuous attention to technical excellence & good design increases agility

To discuss this topic, we've got to start with an explanation of what "technical excellence" means. Technical excellence means maximizing technical value, which is distinct from business value.

When I say "business value," I mean things that fall squarely in the category of being immediately and directly valuable to the business. This includes:

• working features
• the ability to add new features quickly (including the occasional "I need it yesterday" level of quick)
• the ability to test new features shortly after they are produced
• daily updates on progress from engineers
• regular planning meetings between technical & business people

Technical value, the ying to business value's yang, means things that are valuable to the engineers. This includes:

• clean & easy-to-understand code
• automatic tests
• clear direction
• good tools
• snacks (ok, it's not directly *technical value*, but it does help)

By focusing on things that are valuable to us as engineers, we are able to quickly and effectively deliver business value to our clients.

Let's take the first one as an example -- readable code. As an engineer, I can tell you that once a project goes over a few thousand lines of code, there are sections of the code that I might not have to look at for weeks or even months. Without small, well-named functions, and good comments (those that explain the *why* and not *what*), I will have to spend time digging to figure out what I need to change to make the code deliver new business value. Think of these things as signposts that show the organization of the code, the same way that chapters and page numbers show the organization of a book. Finding things quickly is valuable, and if you disagree, then I dare you to not use Google for a month.

A metaphor that's useful in understanding technical excellence is the idea of "technical debt". This was proposed by Ward Cunningham to explain how technical excellence affects the ability to make forward progress.

Let's take Project X. Project X has really well-written code. When a fast change (the "I need it yesterday" kind) comes in, it's safe to incur a bit of technical debt. We'll borrow from our good credit (good code) to hack a solution into place quickly; something only possible because we're organized. Later, when we have the luxury of time, we'll pay off the technical debt by fixing the hack and bringing it back to our usual standards.

The analogy to financial debt is simple: if you keep your credit score healthy, when time and money are important, you can borrow against your credit line. Also, if you have too much debt, you get trapped and spend most of your resources by paying off interest. Same thing goes for technical debt, where the team spends time working around bugs, and trying to figure out what code does, instead of making forward progress on new features.

That all being said, there are responsible ways of using debt, both financial and technical. Imagine a recent high school graduate who wants to go to college, but doesn't have the cash up front. Is it a good idea to take out a student loan? Absolutely! Take the loan, incur the debt, then pay it off when the resources become available. In this case, the student is starting a new venture with future potential -- they are a startup! Same goes for a startup company.

At the beginning of a project, in the prototyping phase, it's ok to take on debt. In Cloudspace's line of work, our clients are often startups. This means that at the beginning of a project, the important thing is for our clients to test out their idea, get feedback, learn what works, and make changes to their plan. In engineering parlance, this means that they need a prototype. It's ok to incur technical debt at this stage, because the business value of being able to experiment and learn outweighs any amount of technical debt. Also, there's so little code, it's very easy to refactor. Recovering from debt is fast. This phase usually lasts for the first few months, until 10-20 people have been able to test the prototype. After that, the learning period starts ending, and like our high-school-now-college graduate, it's time to pay the loan back.

This should give you a good idea of how technical excellence helps keep a project flexible. By having everything organized ahead of time, you can move quickly when it comes time. If you've got questions, drop me a line in the comments. I'd love to discuss them with you.