Below is an excerpt from the book Inside the Minds: CTO Leadership Strategies. The excerpted chapter was entitled Aligning Technology with Fundamental Business Strategies, and was written Michael Broos, Chief Technology Officer of CreditRiskMonitor.

Inside the Minds: CTO Leadership Strategies (ISBN: 1-59622-137-2) is published by Aspatore Books

Golden Rules

There are a number of fundamental principles that I find myself coming back to time after time, in one situation after another. They are based on experience and common sense and are, therefore, not earth-shattering. But they have stood the test of time, and have worked well for me for several decades.

Code is cheap - knowledge is expensive.

Most people are taken aback when they hear this, even many system development professionals (who should know better). The fact is that only a small percentage of the effort that goes into any successful system development project is actual code creation. Most of the time and effort is expended on understanding what needs to be accomplished (business requirements), determining what functions the systems have to perform to produce the desired business result (technical requirements), and deciding how the systems should be organized to best deliver that functionality (technical design). Once there is a clear understanding of exactly what the system has to do and how it has to behave, actually writing the code is almost never difficult, at least in business applications.

The fact that code is cheap can be readily demonstrated. I think nearly every experienced software developer would agree that, once having designed and built a specific system, they could go back and rewrite it from scratch in a fraction of the time that it took to build the original. They've already done most of the thinking and learning required to build the system. All that remains at that point is the semi-mechanical process of translating that hard-won knowledge into executable code.

In my view, technical teams have to be willing to throw code away and start over where it is appropriate. It is very easy to fall into the trap of thinking that you have so much invested in a body of code that you can't afford to do it over. The reality is that most of your team's investment has been in gaining a collective understanding of the problem and its solutions, and that investment is not lost as long as the people remain.

Good people are more crucial to success than good tools.

Very often the questions I'm asked by other CTOs center around which tools we used to create our systems. They never ask about the people who developed the systems. Yet it's clearly the quality and performance of the developers that mainly determines success, much more so than the quality of the tools they use. Tools can help, but they are not a substitute for talent, knowledge, ability, and experience. CTOs need to spend more time thinking about how to recruit and motivate outstanding talent than about which tools those people will use. In my experience, one outstanding developer with mediocre tools will consistently outperform a dozen mediocre developers equipped with the latest "hot" tools. Of course, CTOs should try to get the best tools they can find into the hands of the best developers they can recruit. They just should not obsess over those tools at the expense of what really matters, which is the quality and performance of the people who use the tools.

As an example, we have some striking photographs of wild animals hanging in our home, which were taken by my wife on a photo safari in Africa. When people see them for the first time they invariably ask her what make and model of camera she used, as though the camera itself were responsible for the quality of the images. They just don't get it.

Architecture really does matter.

Architectures that are well matched to the specific set of business problems and solutions being tackled not only save time and money, they also shorten the time to market for new features and enhancements. While it can take some time to think through an architecture, taking the time to get it right is almost never wasted, because architecture has a tremendous amount of leverage. The benefits of a good architecture are realized again and again over the life of a system, which is often measured in decades.

Architectures should not be viewed as simple documents, standards, or guidelines. Wherever possible, components should be bought or built that both enforce and enable the architecture. The best way to ensure that an architecture is actually followed by developers is to provide architectural components (objects, class libraries, SQL views, stored procedures, etc.) that make it faster and easier to develop applications within the constraints of the architecture than to try and work around it. Make the desired path become the path of least resistance and architectural compliance never becomes an issue.

Architectures need to be treated as living things that grow and change over time. While we all strive to get our architectures right the first time, the very act of creating and deploying a system often provides the developers with additional insights into the business problems and their technical solutions. Sometimes those insights uncover flaws in our architectures, or opportunities for making them more flexible or more robust. When that occurs, we need to remain open to the possibility of making changes in an established architecture, even when that means we need to make corresponding changes to the applications built under that architecture. Very often the long-term benefits are worth the extra effort required to ensure that all of the applications are brought into compliance with the revised architecture.

Keep the parts count low.

In my experience, complexity is the enemy of reliability. The more links there are in a chain of components, the more ways there are for that chain to fail, and the harder it is to pinpoint the cause of that failure when it does happen. This applies to all components: hardware, network, and software.

For example, after assuming responsibility for a modest-sized IT organization, I discovered that we had our production data scattered across13 separate data base servers, with a lot of redundancy. There was a complex web of scheduled jobs that attempted to synchronize the duplicated tables, often in the middle of the day. It was very difficult even to determine which data base server held the authoritative copy of each table. Unsurprisingly, the system was extremely fragile, crashing with great regularity. Even when it stayed up, it exhibited unpredictable behavior whenever the synchronization jobs had problems. It took a while, but we eventually redesigned the whole thing, built a single integrated data base, and consolidated those 13 data base servers into one production server and one beta testing server.

Complexity is often the hallmark of inexperience as well. Any novice developer can build something complicated and get it to work most of the time. It takes real talent to design a simple system that accomplishes the same thing. In our shop, we do a lot of iterative development, where we quickly build a prototype from vague requirements, use that prototype to highlight business issues, then incorporate that feedback into a revised prototype, and so on. A lot of code gets built, changed, or thrown away as we converge on the solution. I always know we're approaching a stable system when that code base starts getting smaller. As our understanding of the problem and its solution grows, we're able to strip away the parts that are not necessary, leaving only the parts that are actually required.

Keep it simple. Your systems will fail less often. And when they do fail (as they inevitably will), it will be much easier to figure out where the problem is, and to fix it.