I have a friend who is a hardware engineer. He says he hates software because it is too forgiving. When he designs electronics he has to follow strict engineering practices. One little mistake will likely make his whole design fail and cost his company over a $250,000 to “re-fab” the chip. He has to be extremely careful when he design circuitry.

But we software developers can get away with a lot. If our code is a little disorganized or a quality is missing here or there it will still run and so we often don’t worry about these things until it is too late. Cumulative errors can end up making it very difficult to change a system and at some point we end up with spaghetti code.

The best software developers that I know build all their software to be maintainable; they always follow engineering practices that work for them because it is their habits. Like a doctor who washes her hands before seeing each patient, we developers must have a set of engineering practices that we apply all the time.

If you ever go in for surgery and you see the doctor skip washing their hands then I suggest you get up and leave immediately. The same is true for developers. If you see a developer who doesn’t believe in coding standards or only does them some of the time then I suggest that you consider the impact of their choices.

Software engineers need a set of practices they can rely on. When we make these practices our habits it means we no longer have to question ourselves. Questioning ourselves is a good thing but not all the time. I never questions if I should seeking to make my classes cohesive, I always do because I know that cohesive code have a lot of value.

Sometimes people say to me they don’t have time to worry about code quality when management is breathing down their neck to get a feature out the door. Yes, we must make compromises and rarely can we achieve perfection in all that we do but it is also up to us as developers to make the case for quality because we are the experts in this area. Management might not understand the implications of cutting some corners.

Most everything in writing software is about finding balance and making the right tradeoffs. We must understand the impact of our decisions on our work and seek to minimize cost while maximizing value. Sometimes we have to write a crappy implementation to get it to our customers but let’s acknowledge that we are doing it and give ourselves permission to go back later and clean it up.

One thing that I have discovered about software development is that it is not pay now or pay later. I used to believe that doing things right would pay off in the long run but cost more in the short run. Having worked with outstanding developers who write clean code and do it faster than 99% of the developers I’ve met, I realize it is really about our habits and what we do under stress.

If we make quality our habit then it will always be faster for us to write quality code then to write crappy code. How do we do this? First we need exposure to the right development practices that promote quality without undue burden. The development practices that I promote in my Agile Software Development Essentials class are easy to learn and require no extra time to do yet they have a huge impact on the quality of the code we produce. Then we must keep these principles and practices top of mind so they become our habits.

They say it takes 21 days to form a new habit. In my experience it takes at least a few months to really get good at using these practices. It’s not learning new practices that are the hard part; it is unlearning our old way of doing things. If you are an old guy like me then this may take some time but it is worth it.

The Agile Software Development Essentials class is coming back to San Diego on May 5-7, 2010. For more information, click here.

Why do some teams adopt an agile methodology and become wildly successful while other teams adopt agile and fail miserably? What is the difference?

In order for software development to be successful we must “build the right thing” and “build the thing right”. Agile strives for both but without understanding the goals and how agile aims to achieve them some teams misapply agile and end up getting little value from it.

Agile supports building the right thing by keeping the customer in the room with the development team all the time to answer questions and provide guidance. Some companies say that it is too expensive to give developers access to the customer but how expensive is it to keep developers waiting to get an answer or to end up building the wrong thing? I’d say it is a lot cheaper to have direct access to the customer.

Sometimes management feels that agility usurps their control because they cannot say they will be finished with X features by Y date. Of course, in waterfall you can say it but it often ends up not being true. Isn’t it better to have certainty around one of theses; features or date? For example, with agility you can guarantee that you will deliver working software by Y date but perhaps with a subset of X features. However, this subset will be the most important features to the customer and maybe ones the customer thinks of mid-stream; isn’t that better?

Of course, you can’t build inflexible software incrementally; you have to know how to write code that can easily change. Not following programming standards while building software iteratively will result in an un-maintainable mess. This is where I see a lot of organizations fail with agile and it is easily solved with some essential training for developers.

Agile projects can also fail because of culture. Some corporate cultures require everyone to commit to specific deliverables up front. This does not always work on an agile project. Some cultures see a lack of commitment to long term deliverables as being wishy-washy.

Agility is not just a buzzword. To truly be successful with agile takes understanding and internalizing the agile principles at all levels of an organization. It’s not about reading a book and following the “agile recipe”. Each organization must figure out how to make it work for them.

Building software is non-trivial. Each situation is different and whenever you find yourself in uncharted territory it is good to have a guide. This is why we agile coaches and trainers are in such demand. We have seen how organizations have successfully adopted agile and can help you apply that knowledge to your specific situation. This can make a big difference in how successful you are with agile.

I don’t believe in silver bullets for software development. Building software is very creative and I don’t think we can do it by just following a prescribed set of steps without thinking about what we are doing. And thank goodness. I don’t want to be in a field where I can go on automatic. I like the constant learning and challenge of discovering new ways of doing things.

I do, however, believe in and seek out things that help us be better at what we do. I think agility works because it creates a structure that encourages doing the right things more often.

For example, breaking down big problems into smaller problems is very useful for managing complexity and this is exactly what iterative development does. At the same time it also helps us group and build features in an organized way that makes integrating features easier.

We cannot successfully develop iteratively or employ continuous integration without following certain development practices and paying attention to code quality. Because we welcome customer feedback and changing requirements we must write code that is changeable. This forces us to establish engineering practices that promote higher quality software that can change.

Agility also addresses the cultural aspects of software development. Trusting the whole team to work together and do the right thing empowers us to collaborate more effectively. Favoring face-to-face conversations and working software over artifacts and ceremony keeps us focused on what we are there for in the first place—to create value for our customers. Supporting sustainable development and an environment that encourages improvement helps create teams that get better over time instead of burning out.

By following the few principles stated in the Agile Manifesto we are forced to adopt better engineering practices and a more effective development culture. I believe this is one of the main reasons that agility works for many organizations.

Agile methodologies seem to be taking root in recent years as more and more organizations realize that iterative development done correctly is a highly efficient way to build software. As I see agility gaining popularity I can’t help wondering what the next ten years will hold for agile development.

I just returned from Agile Open Northwest 2010 (http://www.agileopennorthwest.org) and I became very excited. The people there “get it” and are successfully applying agile in a range of environments. I am so wary of fads, which seem to abound in software development. The brief history of creating software is littered with methodologies, languages and tools that have gone nowhere.

Agile is certainly not a fad. The basic principles will probably be in integral part of software development for a very long time. But even in the fast changing world of software it takes time for good ideas to become part of the mainstream.

I talk with a lot of software developers and managers who have never even heard of agile. I also meet lots of teams who say they are doing agile but don’t understand it and are not using it in a way that would maximize the benefits for them. Agility is such a different way of thinking about building software that it is easy to misunderstand at first and the cultures of organizations can be so strong that agility becomes cooped into something far less effective.

I see the next ten years as a consolidation of many of the practices successful agile teams use today. I believe that many of the agile practices we embrace today will become common knowledge in software development in the future. Test driven development, for example, will become more widely practiced for new development and lots of legacy code will be retrofitted with tests. I am looking forward to the day that teams look at writing code without tests the way we look at writing code without compilers today. Sure, you could do it but it is so painful why would you want to?

This is a bright and exciting future but I also see some challenges with agile adoption. As with adopting anything, it takes people time to figure out what works and what doesn’t and to integrate what is new into the old way of doing things.

I was very excited about object oriented programming back in the late 1980’s. I thought it would revolutionize our industry and it did, to some degree, but far less than I had expected. I’ve met very few development teams that use the object oriented paradigm to its fullest. Most teams I see realize some of benefit of object oriented languages but miss using the best features of objects. I hope this will not true with agility but it is almost inevitable. However, this is just part of the adoption process. In 10 years I expect most development organizations will find ways to make agile work for them.

I think the main benefit of agility and object oriented programming is to shift the way we think about problems which, in turn, helps us shift the culture of how organizations approach problems. These things don’t happen overnight and real change does not happen without some struggle but it is also very exciting because we are figuring it out and improving over time.

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

For many people their perfect day involves lounging on a beach somewhere tropical sipping a drink with a paper umbrella in it. That’s nice but my perfect day is somewhat different.

Earlier this week I was teaching an Advanced Software Design class at Microsoft and it came close to being my perfect day. I love teaching this class because it is so interesting and the students are usually very experienced developers who really see the value of the material.

This was a full class and we had several insightful conversations about designing software. The discussion around the lab exercise was particularly valuable. I like the exercise because it is a very thorny problem for which there is no ideal solution. They weighed the tradeoffs for different designs and did the best they could, knowing how their designs could change as requirements unfold in different directions.

Working with groups like this is one of my very favorite things to do. After class I zipped right home since I live less than a mile from campus and joined my wife for a nice soak in our hot tub.

The Agile Software Development Essentials class is coming back to Denver on March 29-31, 2010. For more information, click here.

Last month I wrote an “Agile Tip of the Month” for the Agile University Newsletter. For those who don’t read the newsletter I thought I’d post it here:

The creative genius working long hours churning out code that only he can understand; this is the cowboy coder. How did he get here?

How do people learn the skills to become professional software developers?

This is a question I often ask fellow developers and I usually get very different answers. It seems like we all have arrived at this profession in different ways.

Most of us learn to code on the job and if we’re lucky we find coworkers who are more experienced and are willing to teach us. In this sense, software development is like a craft; we have to apprentice with those who know more than we do in order to gain the necessary skills.

While computer science curriculums are often rigorous they don’t really prepare students for the kind of development that is done in the professional world. The kind of software projects we did in school didn’t require us to pay attention to code quality or develop coding standards. They were small projects that did not require a disciplined approach to writing software. As a result, most new graduates are unprepared to develop enterprise software or work on a development team.

Since most of us are self-taught we often have very different approaches to problems. In some ways this is good because it gives our team a diversity of perspectives that can lead to better insights. The challenge is that we all learned different ways to do things and so the way we approach problems can be very different. This makes for challenges in communicating among team members and also in advocating different, sometimes conflicting approaches to solving problems. Even things as trivial as coding standards and how we name variables can differ widely among developers making it difficult to read code written by multiple authors on a single project.

On one hand we love our independence and the practices we acquired over the years have worked for us so far. But on the other hand we can find it hard to integrate with team members who have a different approach and style than our own. Many of us feel that our approach is better and so we are resistant to changing.

But just like the wild west gave way to law and order in the last century, there is less and less room for the cowboy coder in our modern world. Writing software has become a professional activity with trillions of dollars at stake. Businesses expect high quality software from the professionals they employ.

The old west was settled by very brave and courageous souls who could claim a large area quickly. But soon they had to bring in an infrastructure and establish rules so others could live there and a society could be formed. And so it is true in our industry as well. We must find ways to integrate our work with more ease and that requires a set of basic principles we must all agree upon.

Shared standards and practices indicate a maturing profession. These are what I promote. I don’t claim to have all the answers but I have found several essential techniques that everyone on a development team will benefit from knowing. I share them in the classes I teach, when I coach for clients and on my blog.

Propagating this knowledge among the whole team ensures that all team members are on the same page and communicating with high fidelity to effectively build software that is easier to maintain and extend.