The dark clouds loom overhead. You feel a chill in the air that sends shivers down your spine. Is this the end of the world?

Not quite; but you do have a software deadline closing in, and you are nowhere near done with your assigned feature. You start to cut corners, your Cherry MX Blues clacking away under your fingertips as you commit code that makes you cringe. You are not alone in this; all around you your teammates follow suit. Some of them know full well what they are doing, while others simply do not know any better.

Despite overwhelming odds you push to prod on schedule. Breathing a sigh of relief, you glance around at the other developers strewn about the room. You have defeated the release this time.

But at what cost?

Does this sound familiar? Compromising on code quality in order to meet deadlines? While I am no stranger to the demands of the real world and the compromises that come along with them, I am a firm believer in demanding technical excellence in all aspects of software development.

What is "technical excellence"?

What does "technical excellence" mean? There are a lot of definitions floating around, especially from the agile crowd. Many of these definitions revolve around agile practices, but I want to take a broader look at what technical excellence looks like in practice.

The paper "Technical Excellence: A Requirement for Good Engineering", published by NASA, lists four main components of technical excellence:

• Clearly Documented Policies and Procedures
• Effective Training and Development
• Engineering Excellence
• Continuous Communications

According to NASA, technical excellence is much more than just writing good code. Engineering excellence is just one facet of technical excellence: being technically excellent involves a cultural shift at the organizational level.

Martin Fowler also sheds some light on what technical excellence means in his talk "What Does Technical Excellence Look Like?". The ultimate form of technical excellence that Fowler describes is shortened delivery and feedback cycles. The achievement of this relies on the culmination of the business side of the organization valuing tech and the software development side understanding the needs of the business.

Based on these definitions and my own personal experience, here are the qualities that are required for technical excellence within an organization:

Technology-centric

In order to achieve technical excellence an organization must be technology-centric. It is important to not confuse being technology-oriented and being technology-centric. After all, all software companies are technology-oriented by nature, but not all software companies are technology-centric.

A technology-centric company values tech at a high level. This should be felt at all levels of the organization, from hiring highly skilled technical people to using technology to solve business problems.

Being technology-centric mandates technical leadership. It is the product owner's responsibility to understand the needs of the business and communicate them effectively with developers, but the weight of meeting those needs falls upon the developers.

Technology-centric organizations know that developers own the development process. It should never be the case that developers are just glorified "code monkeys" whose sole purpose is to implement any feature tossed over the wall from product management.

It doesn't make sense to hire smart people and then tell them what to do.

We hire smart people so they can tell us what to do.

— Steve Jobs

Clean code

In the pursuit of technical excellence, one thing that cannot be ignored is the core of what we developers do every day: writing code. This is such an intrinsic part of our daily lives, so it makes sense that it is the largest area in which we can pursue technical excellence.

Technical excellence in code takes the form of writing clean code. This can mean different things to different people, and it can be hard to settle on a common definition of what it means. Despite the subjective nature of the topic, there are plenty of widely agreed-upon standards for writing clean code which should be adhered to.

Things like simplicity, modularity, and loose-coupling are just some of the many ways that developers can keep their code clean. Entire books have been written on this subject, so I would suggest you go and read them to learn how to write clean, high-quality code.

Continuous learning

Technical excellence requires its practitioners to constantly be learning and growing, both as individuals and as a team.

For individuals, this means being willing to learn whatever languages, tools, and patterns are needed in order to perform at their maximum potential. Practices like pair-programming, code reviews, and mentoring are all good ways to share knowledge within a team and help others grow.

Continuous learning for teams means constantly examining our workflows and procedures to identify what works and what doesn't in order to hone our process.

Continuous delivery

Continuous delivery is as much a requirement for technical excellence as it is an outcome.

Achieving continuous delivery requires technical underpinnings as well. Things like version control, automated builds and tests, continuous integration, and automated deployments all work together to make releasing software to users as quick, painless, and hands-off as possible.

Being able to continuously deliver value to the user and gather feedback in short, iterative cycles is what allows software to evolve to meet the needs of the market.

Managed technical debt

In a perfect world we would always take adequate time to design and implement our software. But this is the real world, which means that sometimes we have to make compromises in order to meet our business goals.

However, when these compromises occur it is critical that we, as software developers, are cognizant of the technical debt we're taking on and fully aware of the future cost of paying off that debt. One thing to note here is that choosing to ignore technical debt is not a valid option. Any debt that is taken on has an intrinsic cost associated with it, and one that will need to be paid off far sooner than anyone realizes.

And always remember that when you do take on technical debt, it had better be clean.

"A mess is not a technical debt. A mess is just a mess."

— Uncle Bob Martin

Defined standards for quality

Finally, achieving technical excellence requires defined standards for quality. Without predefined standards for quality it becomes impossible to gauge where your organization stands on the path to technical excellence.

Quality standards should not be developed in a vacuum; they should be based on existing standards of quality that exist in the industry.

Why does it matter?

Now that I've explained what technical excellence is, let's talk about why it matters.

Quality begets speed

One of the common traps that organizations fall into is ignoring the importance of producing high quality software. Not just quality in terms of what the user sees when they use the software, but also the internal quality of the software itself.

This may sound a bit counterintuitive at first, especially to business-oriented members of the organization, but time spent on improving code health and quality pays for itself in the long run. Having a healthy codebase makes future changes easier and allows for new features to be added with a linear effect on the maintenance required to keep the codebase in tip-top shape.

On the other hand, adding features with reckless abandon and with little regard for the health of the codebase—while potentially lucrative in the short-term—will ultimately wreak havoc on the ability to add new features in the future.

In order to maintain development speed over the long-term, quality must be at the forefront of everyone's minds, not just an afterthought.

Quality begets quality

The idea that "quality begets quality" may sound like circular reasoning, but it's the truth. Building software with quality at the forefont will ultimately lead to observable quality for users.

Much like with speed, quality also reduces the number of bugs, which makes it easier to deliver working software to our users.

Because excellency matters

I was hesitant to include this reason as it is a bit of a hard sell to non-developers. But I think that it cannot be understated that excellence for excellency's sake is a noble pursuit.

Developing software is a craft, no different than carpentry or masonry, and developers should desire to be skilled practitioners of the craft.

This is why I, along with many others, adhere to the Manifesto for Software Craftsmanship:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software

Not only responding to change, but also steadily adding value

Not only individuals and interactions, but also a community of professionals

Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

— Manifesto for Software Craftsmanship

If you have your own thoughts on technical excellence I would love to hear them, so give me a shout on Twitter.