I am told that some developers don’t like coding standards imposed on them. I do not have that experience. In working with thousands of developers I notice that they prefer following standards as long as it supports them in doing a good job.

We all hate busy work or pointless activities. If your coding standard is to have a comment for every line of code, like it was for me when I worked at IBM 20 years ago then developers may not follow it because it is _stupid_.

But coding standards that support the team are often quickly assimilated if all the team members see the benefit. However, we may not see the benefit because it wasn’t described to us correctly. For example, one of the most valuable practices I teach is encapsulation of construction. Most developers are familiar with the concept but perhaps never saw the benefit of using it because it wasn’t explained to them well.

It seems like every time you turn around someone has a new tool or methodology or something that is supposed to revolutionize our industry. No wonder seasoned software developers have become jaded. We often find what works for us and stick to it. We resist the flavor-of-the-month methodology because we’ve seen too many come and go.

But since we work in such a fast changing industry we have to reevaluate our knowledge on occasion so we continue to learn new things. This is true for other fields as well. Most M.D.’s spend at least 12 hours per week reading journals. Even CPA’s are required to get several days of training each year in order to renew their license. We developers have to be even more vigilant.

Far too often I hear managers say, “Just get it out the door.” I understand the perspective. We work in a world of constraints and the business needs to survive.

Management often says this but really mean “I look to my developers to tell me what critical things must be there in order for the business to derive benefit.” If we are being asked to deliver something with such low quality that the customer or the team will pay for it later then we must help management understand the cost of their decisions.

We are not looking for perfect code. Building software is a series of compromises and the developers who are writing it are the best informed to make the wisest decisions on which compromises to make.

We all want to be proud of our work but we also realize that being a perfectionist is often not desirable and we must find a middle ground. Sometimes we have to ship code with serious flaws but we should be aware when we do and make a case for cleaning it up later as good for the business’s ongoing investment in their software assets.

Have you ever stay up until three in the morning trying to track down a bug? Maybe it was code that you were charged with maintaining or maybe it’s something you just wrote. Remember how it felt trying to figure out what the author was doing?

Who is our customer? You may think it is the person who uses our software and they are very important but we have another customer we sometimes forget, you—that you that is trying to fix a bug at 3:00 am. The people who maintain our code are also our customers and we must write software for them as well.

When we consider that over 80% of the total cost of software happens after it is released we can see that maintainability of software is critical to success and that we must drive the cost of ownership down.

Our software must do the right thing but just correctness is no not enough. The code that we write must be easy to understand, maintain and extend. But how do we do this? What makes software easy to understand, maintain and extend? This is what we will look at in upcoming posts so stay tuned.

How do you define quality? Ford says that quality is job one but what is it and how do we create quality? We all recognize quality service at a fine restaurant and a quality product like a fine piece of furniture but what is quality in software?

I ask this question a lot to developers in my classes. Often I get answers like the software should do what it is supposed to do or it should not be slow and buggy. These things are important but the kind of quality I am talking about is internal quality; how well the software was written.

Software is non-tangible. It is governed by different forces than things in the physical world but it is governed by forces nonetheless. One of the key forces that affect software quality is complexity. When software is overly complex it is prone to bugs.

Some say that because the end user has no direct experience of code quality that quality is not important in software. This is a position maintained by people who have probably not written much software. Just because a piece of software is behaving correctly right now doesn’t mean that it will be easy to add new features to it later. Without the ability to fix bugs or improved a product, users generally lose interest and software generally loses market share.

How do you define software quality? What makes software good and how do we achieve it?

When I show students in my classes a particularly bad design and ask them to evaluate it, they feel uneasy but very few have language to describe what is bad (or good) about a design. Without a common language that distinguishes good code from bad code we have little power.

Reviewing a design is like critiquing art. We can recognize what we like or don’t like but we often can’t describe what makes a design good. Without this kind of language it is very hard for teams to generate good designs and quickly gain consensus.

This is why I am such a big believer in code qualities. Code qualities are specific, easily identifiable features of good code; code that has stood the test of time and proves to be easier to maintain and extend.

I talk about six key code qualities but there are many more. I point out six because they are easy to see and often focusing on just them is enough to guide us to write good code. Of course, they are only guidelines and there are times when we want to abandon them, like for performance or security reasons. But most of the time code qualities are good to strive for when we write software.

I will describe these qualities in coming posts. They are all easy to understand and you are probably already familiar with them. However, when we use them the benefits are so great that it is worth keeping them top of mind.

Retrofitting tests into legacy code is difficult process but can give us the ability to redesign and improve the quality of that software as we go. It is generally a good idea to add tests before refactoring code. Tests serve as a safety net so if I make a mistake in refactoring the test will tell me.

Sometimes we need to refactor code in order to add tests. These are generally simple refactoring or what Michael Feather’s calls “safe refactorings” in his book Working Effectively with Legacy code. Several IDE’s provide facilities for automating safe refactorings. Once tests are added you can do more complex refactoring.

It is always a good idea to make a test fail before making it succeed. How do we do this when we are retrofitting tests into working code? The answer is to temporarily change the working code. For example, if I am writing a test for code that sums 1 and 2 then I’ll hardcode a return value of 1 to make it fail, then I’ll watch it fail and then I’ll back out my change using Control-z and watch the test succeed. This may seem like a pointless activity but you may be surprised at the times you expect a test to fail and it succeeded because of something you weren’t expecting.

If we are going to take the time to clean up legacy code then we must do it in a way that we don’t end up with the same problem years from now. If we want our software to survive and continue to be used and changed then we simply have to start building it with some core engineering practices that support change, including unit tests.

Part of allowing change to happen during development is by building software with engineering practices that support change. The most important of these practices is correctly using unit tests. Tests represent a way to both embody understanding of the system and prove that the system works.

Unit tests are really a form of specifications because by running them and seeing them succeed we know they are up to date. So we really want to use test as a form of documentation that specifies the behavior of a system.

This implies using unit tests in a different way than many people think of them but it is perhaps the most powerful way to think of using tests. It also guides us for creating the right number of tests. If we see tests as documenting the system then we are not tempted to write more tests than are needed to specify the behavior of the system.

I notice that I can learn a system much more quickly when there are tests in place. I invariably look at the tests first and that tells me how the system should behave. I then look at the production code to see how the behavior is implemented.

The biggest impediment to change is a cultural one. Change means things are going to be different and human beings resist this at some level. Change requires being able to adapt and this can be difficult so as a result we tend to resist it.

I often run an interesting experiment in some of my lab classes where I give students an assignment to build a piece of software but I only give them some of the requirements up front. The requirements I give them seem to lead them down one certain approach to design but later I give them another set of requirements that really requires them to change the design they initially adopted in order to accommodate the new features.

What I find is that few developers will quickly embrace changing their existing code because there’s a culture around not changing code. When we change code it becomes dangerous, that’s when bugs get introduced and we may not totally understand the code even if we wrote it ourselves. Changing code always represent some level of risk.

This fear of changing code is absolutely antithetical to where our industry needs to go. We need to build up the confidence to be able to write software that we can then later change or else our software will slowly cease to provide value.

To build the confidence to change code we must adopt practices that support us in writing code that is changeable. Most importantly, having unit tests in place gives us a safety net so that if we make a mistake or introduce a bug we find out about it immediately through a failing test. With a suite of unit tests in place the resistance to changing code begins to fade and we become more confident in changing the code, which in turn lets the software continue to deliver value for customers in the future.

The Agile Software Development Essentials class is coming to Dallas on June 28-30, 2010. For more information, click here.

Back 25 years ago the way we started to write a new version of a successful product was that we deleted the previous version and started with a clean slate. Virtually all the code we wrote was thrown away and many new versions were started from scratch.

But we can’t do that today. The systems that we build today are much larger and far more comprehensive than anything that we did back then. It doesn’t make sense to start from scratch when we write a new version of an existing product and so we have to think about the software that we write differently.

Building architecture has come to realize the same thing. In the old days a house or store was built specifically and only for that one purpose but today we see suburban areas become urban areas. Houses become shops which become common spaces and so the way buildings are built today have to be more flexible and accommodating so that when neighborhoods change the buildings can be more easily repurposed. This implies a retraining of building architects and the practices that they use in order to construct these newer buildings.

The same thing is true in software development. If we want to start building software that is able to be repurposed then we have to rethink how we build software in the first place and we have to identify what makes software easy to change what makes software difficult change.

It turns out that the practices for making software easy to change our very straightforward and not hard to learn. I cover just a handful of these practices in my classes and although not exhaustive by any means they’re a great start and makes a huge difference when put into practice on a development team.