Value Relationships Over Code, Sometimes

There are times when a senior developer allows a junior developer to use a suboptimal solution because the junior developer is emotionally attached to solution and building a relationship with that developer is more valuable than optimizing that bit of code.

The Way of the Software Architect – the first allegory

The CEO came to me and said he would like a new web site.  I replied that I am a client/server software architect, but that I could learn to become a web architect and build his site for him.  I went to the masters of Ruby on Rails and in just two weeks I learned to create a site and I learned the power of convention over configuration.  Then I went to the masters of ASP.Net and in another two weeks I learned the many benefits custom controls and the Microsoft Way.  Then I went to the masters of PHP and I learned the simplicity and elegance of the PHP way.  Then I went to the masters of MVC and learned the testability and power of the MVC way.  I went to the masters of Silverlight and learned the power of .Net in the browser using the C# way.  Finally I went to the masters of HTML5 and javascript and learned the breadth and reach of the HTML way.  I learned each of these technologies in two weeks each.  I returned to the CEO and said, “I have learned many of the best web development frameworks.  I have developed web sites in each and I know the strengths and weaknesses of each.  I am now ready to build your web site for you using the very best approach.”  The CEO looked at me and said, “You are too late.  I told my 17 year old niece about the web site I desired and she created it using Google sites in two days.  The site she created is perfectly satisfactory to my needs.”

 

— The architect’s way

 

This story illustrates the necessity of the architect to understand more than technology.  Indeed, for every person involved in a software development project, the goal of your tasks is not to provide an esoteric best answer.  In the role of a software architect, your goal is to recommend the best architecture.  But every person in an organization has many roles, and one role shared by every person is to help solve business problems quickly and efficiently.  Often, the business goals trump the goals of the software architecture.  Business goals include:  getting to market early, pleasing a specific client, pleasing a specific CEO, developing a secure solution, developing a prototype solution; development a solution inexpensively that is good enough; allowing a junior developer to learn through trial and error by developing a solution; developing a solution merely to learn a new technology; developing a solution to test out a new technology before using it in more important projects.  All this and more.  A software architect needs to help a business solve business problems first, and worry about purity of architecture second.

Advertisement