Recently, I was a lucky recipient of a free book on software development titled “Domain Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans. Many people in the field consider this book a “classic”, and I quickly found out why. Reading the book sparked my motivation to finally do something that I have been meaning to for sometime; this was to capture (at least for my own benefit) a list of good practices for delivering great software.

One decade of reading, working and observing a lot of smart people in the software development field has provided me many insights into why some software development teams “click” and deliver great software, and also why other teams seem to simply whither away after only a few days or months of working together. Some of the key insights that I have are, very oddly enough, nothing to do with how programmers actually code but rather how software is conceived, designed and delivered through a close collaboration between users and programmers. My key insights are (in no particular order):

1. 1. Bring enthusiasm to work, and be friendly
   

How many times have we all worked in a team where there were at least one or two individuals who considered their work simply a chore, and never had interest in it otherwise. These individuals simply rob all fun and enthusiasm from the rest of the team by their constant grumpiness and moping. I have even had to put up with a few individuals during the course of my career, who although considered very “productive” by some, were  single handedly responsible for ruining any shared chemistry and synergies within the team due to their unwillingness to work with others and their total dislike for collective success. However, I have also been incredibly lucky to work with people who always shared an infectious enthusiasm and positive attitude when tackling any challenge that came their way (not just in the software realm), and always managed to be cheerful and friendly even when having a seemingly bad day at work. Teams comprising of such individuals are so rare to come by that most programmers (including me) would gladly consider working even for less pay to share in the fun and learning that almost always happens in such environments.

2. 2. Understand the user’s business/domain
   

This insight has very special meaning to me these days because this was one area that I really didn’t pay attention at all until much later in my career. I was so focused on developing “frameworks” and other cool gadgetry to support the “structural” foundations of the software that I almost never paid attention to learning a little bit about the problem domain that I was writing the software for. The lack of knowledge sometimes hindered me from truly delivering the kind of software that not only addressed any current needs of the end user, but also one that permitted easy enhancements in the future. The people that I have come to admire these days are the folks who through the course of any software project become so savvy in the end user’s domain, and are able to forge great relationships as a result between the software team and the end users.

Many successful projects that I have participated in included design sessions where the end user (or a business analyst) starts by providing a high level overview of their business area/domain as well as summary of the problem they are attempting to solve. Even when this took a few days (or weeks depending on how large and complex the problem was), this was only a small price or “sacrifice” to pay for the rich interactions that usually almost always followed later since the programmers now had a good understanding of the end user’s domain. This, in turn, permitted them to develop software that addressed their needs. Another advantage that this approach provided was that these interactions often permitted end users to gain insights into the abstraction and modeling processes that are often used by programmers. The combined benefits allowed both parties to have meaningful dialogues and a deeper understanding of the problem at hand. This always led to the formulation of clear requirements, and good software consequently emerged.

3. 3. Never do requirements in isolation
   

I have a big chuckle these days when I hear a programmer asking for a “detailed software requirements” document before they can begin work. Now, don’t get me wrong here. I am not saying that we shouldn’t bother creating documents containing detailed specifications of the software that we plan to build. But, to ask the end user or a business analyst to write this document in total isolation and simply hand it to you is really asking for trouble. How often have many of us seen “requirements documents” from end users or business analysts that really do not have any requirements at all, but rather contain a hazy/distorted vision of the final solution itself. This only creates frustration for the programmer who now has two tasks in front of him/her: 1) infer the real requirements from this preconceived “solution”, and 2) develop the right design for this software (based on what will now be only considered “his/her” vision). This method often (and unintentionally) leaves end users frustrated (and sometimes offended as well) since it makes them feel as though their ideas were totally ignored, leading to a lack of buy-in later on. So, my point is that we all need to work with the end users as the requirements are captured/formulated.

4. 4. Model after the real world
   

The book I refer to above is bang-on on this topic. I have witnessed many failed software projects where the development team insisted on using a completely unique set of terminology to aid in their understanding of the user’s domain. Although some abstractions are always necessary when modeling software, abstracting too aggressively will result in confusion during any inter-team communications due to the need to translate the lingo back and forth between the teams. To communicate easily, the design model must be easily understood by both parties. This results in collective ownership of the software due to the investment in this shared model of understanding on which the software is based.

5. 5. If it won’t run, it is garbage
   

On one project in the past, a team was looking at deploying software that had been written by seemingly bright individuals. The software was throwing cryptic error messages during the install process, and the administrators were making no progress at all. When the support team reviewed the code, they noticed right away that the code was extremely hard to read, understand and modify. When approached for clarification, the original programmers of the software spewed some mumbo-jumbo about all the “advanced techniques” and design patterns they had apparently utilized in developing this software, and directed the blame at administration team that was attempting to deploy this software. My take away from watching this fiasco unfold was that it didn’t matter what is “inside” the software, but if you cannot run and administer the software easily, it is really garbage.

6. 6. Read and talk about software
   

Most of us who work in great teams will agree that the best software teams chat frequently about software development. Despite constant chatter and passionate discussions within these groups, one can notice that this environment always generates enthusiasm and excitement which forges the teams together. This insight has provided an added benefit for me in that it has kept me very humble due to the realization that happens very quickly that there are many aspects of software development that I have simply no clue at all, and it inspires me to read and understand those topics further

7. 7. Read widely
   

At a software conference that I attended some years ago, I became convinced of the many benefits of reading outside of one’s area of specialty, or “focus”. A speaker had invested significant amount of time and effort researching a problem that had risen recently in the software industry, and during the course of his research had even read studies conducted in areas that seemed unrelated to software. While doing this, he had found a number of elegant ways of tackling a similar problem that had risen and been successfully addressed in another industry (town planning and building construction). During his very captivating presentation, he first proceeded to illustrate the many “parallels” that existed between these two seemingly unrelated industries, and later explained why the same approaches would work in tackling the problem in the software domain. The breadth of knowledge in this man was extraordinary, and this allowed the speaker to come up with an elegant solution without having to “re-invent the wheel”.

8. 8. Listen for feedback
   

Very few teams seem to do this, but teams that do gain immensely. By talking to the end users after the software has been deployed for use, we can easily learn what went wrong (or right). With this understanding, teams can either repeat (or not repeat) practices that were followed during the course of a particular software project.  In the past, I have been very guilty of not following this practice myself, choosing not to call the end users after the software has been delivered out of fear that I would only hear complaints from them. However, when I did force myself to do this in a disciplined way, I was often pleasantly surprised to hear more good news than bad. Even during the few occasions where there was mostly bad news, the end users were somewhat relieved to see that you shared in their problems, and it helped diffuse any potential tension that would have otherwise been detrimental to the relationship in the long run.

P.S: In the picture with me is James Gosling who I had the good fortune of running into very recently. He is the inventor of the Java programming language and software platform that powers approximately 2.4 billion devices including cellphones, PDAs, computers, computer applications and smartcards. He has a “rockstar” image among programmers for helping develop the “smarts” behind the World Wide Web in its early stages, and yet remains a very humble man to this day. He is one of my heroes. This picture was taken at the recent Oracle OpenWorld software conference in the city of San Francisco, United States.