In my last post on this topic, I looked at some of the commonalities between learning to play a musical instrument and writing software. In each case, there are “rudiments” to be learned, boring though they may be, that help one become great at either craft. In this second installment, we’re going to look at what happens when you’ve finally learned to play and decide you’re ready to take the next step: Composition.

Finding Your Own Voice
There us a huge difference between playing the notes written on a page and making music. When we find a piece of music we really like, more often than not it’s the feel of it that draws us. More than the simple, linear arrangement of notes or chords, it’s the interpretation of those notes through the act of performing that makes a simple sheet of musical notation actual music.

For many musicians, this is more than enough. But for some, the satisfaction of simply playing music written by others wanes quickly and they seek to find their own voice, to express their own ideas, their own reflecting glass for their experiences. So they turn their energy to musical composition.

To be a successful songwriter or composer, you need:

• Experience: First and foremost, you must have mastered the art of playing music before you can master composing music. I’m certain that this is an arguable point (I’ve never seen a point that wasn’t), but in my experience, those who can’t play generally can’t write very well either. They tend to have unrealistic expectations of the musicians that will need to take what they’ve written and perform it. They also tend not to have a good feel for what musical structures fit well together and sound most natural to the human ear. It’s that sense of recognition and comfort, after all, that differentiates what people consider music from background noise.
• Creativity: This seems like kind of an obvious one, but you’d be surprised how many people I run into that try to write music based on an astoundingly detailed knowledge of musical theory. Certainly, theory provides you with the tools to understand the what of music, but the how, and more importantly, the why must come from the mind and imagination of the composer. Without creativity in composition, we’d still be listening to waltzes and chamber music, the lute would still be the string instrument of choice and percussion would be optional (though some may argue it is anyway). Human creativity pushes the envelope and fosters an environment where the art can evolve beyond the status quo.
• Knowledge: This is related to experience, but is slightly different. Imagine you’re composing a piece for a major symphony orchestra. Think of all the individual instruments for which you’d need to write parts: Violins, violas, cellos, basses, winds, brass, percussion, etc. And within each instrument group, you need to write the first part, second part, etc. If the only instrument you’ve ever studied is the clarinet, then you’ll likely write a fantastic clarinet part, but will likely find it very difficult to successfully write all the other parts in a way that leverages the strengths of each instrument and creates one unified piece of music. Understanding and knowing the composite parts of the larger ensemble of instruments will certainly lead to a more cohesive and sonorous piece of music.

The Composition of Architecture 
Musical composition clearly has parallels to the software development process when you consider the role of the architect, vague though the definition of that role can often be.

In my experience, I’ve found it very unusual to see successful architects that didn’t start out, in some capacity, as software developers. What I find to be the case more often than not is that the best developers on a particular team gravitate into the role of the architect, either de facto or de jure. I can’t speak for all architects that followed this particular career progression, but I can speak for myself.

I was drawn to software architecture for a couple of reasons:

1. Writing software handed to me and designed by someone else started to hold less interest day-to-day for me
2. I felt I had good ideas for designing systems and wanted to be in the position to express them

In other words, I wanted to stop just being a “performer” and wanted to become a “composer” because I saw it, primarily, as a venue to better express my technical ideas. That being said, I still code as often as I can (which isn’t very often these days, but I do find time now and again). I’ve never met a composer who didn’t continue to play on a regular basis, even though it wasn’t their primary vocation. We do this because it keeps us sharp and in touch with the ultimate results of our work. If we can’t play it, it will be difficult for others to play it. Some of the worst architectural designs I’ve seen have come from architects who never paid their dues in the trenches writing code and making software work on a real project. I once had a friend who told me, “True wisdom comes from great pain and suffering.” Over the years, that dictum has been proven true time and time again.

I think that creativity is one of the most overlooked characteristics in successful software developers and architects. When we think of people who work in software, it’s easy for us to picture the long-faced nerd with an overbite, thick black glasses and a picket protector tucked into the front of wrinkled white dress shirt, purely analytical and socially inept. While the industry certainly has its share of those archetypal individuals, it’s also filled with mainstream, highly creative people who simply love the malleability of software and the ability to make it into just about anything you want or need it to be. Like music, software architecture has “theory” (we tend to call it “best practices”) that, if followed, get you moving in the right direction, and ultimately it’s the creative use of those guidelines that allow new ideas, techniques, and yes, best practices to be tried and vetted. It is creativity, I think, that makes a lot of musicians and other folks with artistic backgrounds who work in the software industry so successful. Because the tenets of theory are more guidelines as opposed to hard rules, musicians tend to be more comfortable experimenting with things that haven’t been tried before. Musicians don’t have a corner on the creative market, of course, but for the most part they have active, creative minds that can drive the “next big idea” to make developers, architects and the products they produce better. When you stop to consider something like test-driven development (TDD) and the progenitors of that movement, it’s easy to see the important role creativity can play in building better software. Many people would call this “Thinking outside the box.” A creative approach to developing software precludes the idea of a box in the first place.

Certainly, the role of knowledge in software architecture should be self-evident. In this case, it also warrants a discussion of its own and will be the topic of the next and last post in this series: Teaching.

Code reviews should be built into every project timeline. What I find most of the time is that they are overlooked, excluded in lieu of functional testing only, or worst of all, performed by the wrong person. This is shame because a code review can significantly enhance a team's chance of delivering a quality piece of software that the customer will actually use.

There are several ways of conducting an effective code review, some very laize faire and some very hands-on. The key is combining the power of review tools with an architect's personal and professional experience to yield the most effective review possible without taking inordinate amounts of time away from the project itself.

The following are three tips I'd like to offer to help you get the most out of your code reviews.

1. Do Reviews Early, Do Reviews Often
The first three weeks of a project are the most crucial. It is during this early time that the foundational parts of the application are being developed. This will be the first and best opportunity for issues in this vital part of your application to be identified and fixed inexpensively. Every day that goes by without identifying a critical defect in the code will cost you exponentially down the road in lost time and money.

The first key to a successful code review is to start reviewing the first day of the project. Look at code written by all the members of the development team and make sure that they are heading in the right direction. Some important things to look for in these early reviews include:

• Are they correctly implementing classes, interfaces and layers per the system design?
• Are they leveraging any reusable utility components in your organization?
• Are they using established naming conventions, either industry or organization specific?
• Are they implementing proper exception handling, i.e. not swallowing exceptions?
• Are they properly closing database connections, streams, etc.?
• Is there any redundant code that can be consolidated?
• Are they properly addressing tier requirements for the system?

With a focus on these specific items, I recommend that you do daily code reviews for the first three weeks of the project, providing feedback to the team the same day. By identifying these fundamental structural issues before thousands of more lines of code are written on top of them allow your team to address them while they are still easy and inexpensive to fix.

This process also provides the architect a great opportunity to mentor your development team. Looking at their code will be a great indicator of how experienced they are and sharing your feedback will help make them better developers down the road.

After the first three weeks of the project, you should be able to back off the daily code reviews and start doing them every couple of days instead. By this time, your team should have firm expectations what they need to do and solid direction going forward. Ideally, within a month, you should be able to move to weekly reviews with minimal risk of missing something important. Of course, every project and development team is different, so use your best judgement as to the effectiveness this approach offers at the start of each new project.

2. Tools: Trust, but Verify
Any software vendor that you talk to will tell you that their static analysis tools will catch most of the bad stuff in your code, and the only ones you should be considering should allow you customize the rules that the tool applies in its analysis.

However, analysis tools are just like any other piece of software: They're limited by the number and quality of rules provided them to do their job. Most static analysis tools I've worked with in my career provide good starting points for a more in-depth, manual review.

Think about a code analysis tool like Cliff's Notes. Cliff's Notes were meant to be a study assistant while reading a particular book, not a replacement for the book itself. However, ask any group of high school English students and I'm sure you find them enjoying the Cliff's Notes for Huckleberry Finn without a copy of the novel anywhere in site. While this will give you a high level overview of the plot and the major themes, nothing can replace the level of detail you'll only get from reading the book itself.

Also, Cliff's Notes are not always correct. I remember using Cliff's in college for some 18th century British novel I was struggling to get through (I wish I could remember wish -- it was dry as hell). I got through the novel, but depended almost solely on the Cliff's Notes to arm me with the information I needed to discuss it in class. As it turns out, we were using an alternative version of the original text and I was missing several details which made me look like an idiot in front of my classmates.

If anyone out there used FxCop before it was (arguably) improved and integrated into Visual Studio Team System, you know that tools can't always be trusted to return an accurate representation of reality. I once wrote a "Hello World" console application in C# and FxCop told me I had over 1,200 defects in my code.

The point of this is to use code analysis tools as a means of "sniffing" your code for potential problems. Look at them as sign posts to something you should investigate further. Sadly, I don't think we'll ever see a tool that will deliver the same, high-quality results as actual human eyeballs on the source code. "Trust" that the tool is pointing you in the right direction, but "verify" that there is really some fire to go with that smoke.

3. Actually Read the Code
Building on the previous section, nothing can replace actually looking at source code. This is definitely time consuming, but will yield the best results. While code analysis tools will catch naming convention violations and orphan variables, actually looking at the code will provide you the context of those issues, especially in the structural integrity of the application as a whole.

The other benefit is that it gives you more visibility to what your developers know how to do. In my first bibliography class as an undergraduate, I was fascinated to learn that literary scientists had been able to identify individual typesetters of Shakespeare's first folio by the grammatical and spelling errors they made setting type on the printing press. The same principle can be applied to reviewing developers' code. It will help you identify strengths and weakness in individuals' coding and allow you act accordingly.

Reading raw code isn't necessarily to most exciting or desirable work in the world. In fact, it can be downright tedious and tiring. However, it is the most sure way to make sure that your project is proceeding the way it should be in development, so budget time to sit and just read and understand the code being written for your project. If you do, I can guarantee you'll reap the benefits later.

Just Do It
Hopefully you'll find these tips useful in getting better quality results from your development projects. I absolutely recommend trying these techniques out on your next project, but also encourage you to try them out on your current project, even if it is well underway. You may not get all the benefits, especially from the early and often reviews, but doing some level of review is better than doing none at all.

I welcome your input, experiences and additional best practices. Please leave a comment if you have something to add to the conversation.