Monday, June 6, 2016

97 Things Every Software Architect Should Know

Monson-Haefel, R. (2009). 97 Things Every Software Architect Should Know. Sebastopol, CA: O'Reilly Media Inc.


"97 Things Every Software Architect Should Know" is an anthology of advice from industry experts prescribing through their individual experiences, what a software architect should be like. Compiled by Richard Monson-Haefel, this collection of articles elucidates the role of a software architect within the context of a business. 

Valuable Insights

Although the compendium has a number of articles which I find helpful while being slightly disputed with some, I find the following three "things" the most valuable.

Architectural Tradeoffs

[Thing #22 | Mark Richards]

A software architect must always be aware of the trade-offs that exist in every quality goal that she attempts to achieve. She must understand and communicate effectively the impact of achieving those and the risks involved to the stakeholders of the project while evaluating and making decisions to best reach the quality goals. 

The author of the article, Mark Richards, give the example of the Swedish endeavor to build a ship called the Vasa. In the 1620's, the King of Sweden, in efforts to defeat Poland, commissioned the building of this ship. The requirements of the ship were extravagant requiring the ship to have unsurpassed abilities. The architect of the ship had no experience in designing ships of the scale of Vasa. He did not communicate his reservations about this ship to the king but instead designed to ship as he would a smaller one. In a tragic turn of events, the ship sank within a few minutes of setting sail.

I personally believe that all risks and qualities should be communicated with the stakeholders of a project so that a decision can be made which best suits the requirements. Working onsite with the client, I have, on numerous occasions, had to ensure that the client as well as my colleagues and I understand the risks involved in certain requirements. I may not have used formal methods such as ATAM or CBAM. However, I believe that I have been instrumental in driving the team and the client towards acknowledging certain risks.

This article served as a refresher for me for a graduate course I had namely "Software Architecture and Product Lines". I was lucky to have been taught by a senior member of the technical staff at the Software Engineering Institute (SEI).

Understand the Business Domain

[Thing #30 | Mark Richards]

Software architecture is generally viewed as a very technical and dry subject. However, it is important for a software architect to understand the domain of the business that she is serving. This will inspire the software architect to think of what the actual business problem is and how it can be solved keeping the most effective returns to the business. This naturally leads to architecture patterns which best serve the purpose.

Understanding the business domain will also give the architect insight into regulations that are required for the client's industry. For example, a health care business will require HIPAA compliance to ensure customer privacy while a retail business accepting credit card payments will require PCI compliance for secure transactions. The architect, armed with this information, can make clear decisions regarding the design of the application as well as the scope of components affected or involved in these.

Similarly, when the architect understands business trends, she can create sensible solutions and patterns which serve the business to lead those trends. For example, a banking application depositing checks through a picture taken from a mobile phone can be path breaking and reduce the lines at the ATM machine as well as the teller.

This is one of my favorite articles in the book as it expresses the need for a technical person to immerse into the depths of an industry outside of their comfort zone. Furthermore, I will assert that even the developers and QA engineers must make efforts to understand the business domain they are working in. Lost in the world of programming, we tend to forget the reason for the work we do. Understanding the business domain will enable the architect as well as the developers and test engineers make decisions which make the best sense for the business.

Your Customer is Not Your Customer

[Thing #82 | Eben Hewitt]

One of the major aspects of working in a software services company is the tendency to believe that the applications one builds servers the client it is delivered to. This leads to fallaciously looking at the client as the customer. Eben Hewitt highlights through this article how misleading that may be to an architect to accept the word of the immediate client as what the software system requires.

There are a number of things that the customer does not think are required. However, they may be requirements which may affect the end user. Non functional requirements are usually the ones targeted to get the axe. On many occasions, the customer may emphasize that the core functionality be built first and then the peripheral qualities. However, these may negatively affect the entire application itself. For example, a banking system without proper security measures is bound to fail. Similarly, a system for which it is expected that hundreds of users interact and perform concurrent processes cannot be developed on a framework which is single threaded. Such systems may solve the functional challenges but will collapse.

Requirements gathering should not turn into design and implementation discussions. The customer must only discuss their requirements without delving into how they should be implemented. I have been affected by one such situation with a client. I had been given a view of how the end users currently work and expect certain data. I erroneously used that information and designed an application which would correspond to exactly that. Being careful to develop just a Minimum Viable Product (MVP), we still saw that the manner in which the "customer's customer" received the data was a daily report. I designed the system with the same information as an online system. The design flaw was revealed at runtime when a single query took over a minute to execute. This caused frustration to the end user.

I ended up designing a far more effective system in the end, however, this was a great learning experience. One must listen to what the customer's customer wants, needs and expects rather than being led into implementing how they want it served.

Sunday, June 5, 2016

The Clean Coder: A Code of Conduct for Professional Programmers

Martin, Robert C. (2011). The Clean Coder: A Code of Conduct for Professional Programmers. Old Tappan, NJ: Pearson Education Inc.


The book, "The Clean Coder", focuses on aspects of the working life of a programmer in the software industry. Robert C. Martin ("Uncle Bob"), through this book emphasizes on the various aspects in which a programmer can be and appear "professional". He explores, through his long experience as a programmer, the behavior of software developers and how they are perceived by other professionals in the industry.

This book can be described as a manual for the coming-of-age of a software development professional from a scruffy hacker who would be non-committal and tardy to a clean coder who asserts professionalism through her behavior and work. I have personally had an education in professional software development through the software engineering program for my masters. I have described in previous posts how software engineering is different from Computer Science. This book, although does not acknowledge that difference, emphasizes on the needs of the industry which closely match with the software engineering discipline.

Valuable Insights

The book visits various aspects of software development ranging from inter-personal conduct to self-improvement to growth as a professional coder. The following aspects stood out to me. 

Work Ethic

[Page 16 | Professionalism]

The first chapter of the book gets right down into the behavioral facets of a professional. An individual's career is their own responsibility. This requires them to maintain a work ethic which distances them from their employers in a way. One of the usually observed behavior traits from employees is when they feel entitled to certain perks from the employer regarding the career development of the employee.

The employer is not responsible for how the employee's career shapes up. The employer has and must have a professional business relationship with the employee. This means that the employee must demonstrate that the employer receives the services that they have agreed upon. The employer may have the employee undergo a training program or attend conferences on behalf of the company. This should not be looked at as a perk void any benefit to the employer. 

This leads to the programmer being committed to deliver the services promised to the company in the promised time. A part of this also means that the employee must not work beyond the commitment. This ensures that the work of the professional is valued.

Being a "Team Player"

[Page 30 | Saying No]

One of the key attributes of a professional, which probably is a cliché in job postings and resumés alike, is that of being a "team player". However, very few care to explain what the term really means. One tends to translate the phrase to being person who always agrees with the team or expresses agreement on behalf of the team. 

A team player, as Martin explains, is a person who "communicates frequently, keeps an eye out for his or her teammates, and executes his or her own responsibilities as well as possible." He further goes on describe a conversation between two colleagues who are trying to negotiate the estimates of work to be completed. We see that Mike has already committed on providing a demo to the Director of Development, Don, on behalf of the team without consulting the team. He later tries to push Paula towards his personal goals of impressing Don. Paula, however, stands strong and defends the team from taking an impossible task. The author shows how Don may perceive Mike as a team player as he might be able to get the team do a difficult task, but Paula is the real team player who stands up and defends the team's interests.

I have experienced this at multiple occasions in my professional life where someone commits on behalf of the team and ends up wildly overestimating the efforts. This results in a low morale in the team as they have to put an extra effort in fulfilling a commitment they weren't a part of. A professional must be a team player; she should play for the team.


[Page 127 | Time Management]

Away from the inter-personal behavior highlighted earlier, the author later in the book throws light on personal behavior and management. This includes managing one's time to achieve better productivity. An important part of managing time is to be able to focus on the tasks at hand.

Martin describes the ability to focus as a scarce resource not unlike the biblical manna or its namesake from role-playing games like Dungeons & Dragons. We are most productive in writing code when our focus-manna is high and we feel its lack when we lose alertness and attention. Perhaps, it is similar to a writer's block. He goes on to explain how certain activities can affect our focus-manna.

  • Sleep: One must have an adequate amount of sleep to be productive. I cannot agree more with this statement. I have personally experienced, and I am sure a lot of people have, the lack of alertness and focus when I had inadequate sleep which cannot be helped even with a healthy serving of caffeine.
  • Caffeine: I do not entirely agree with the author on the use of caffeine to create alertness. I do drink a good amount of coffee in a day myself, which sometimes makes me jittery. However, I feel that the jury is still out on the effectiveness of caffeine on someone who is not in the habit of drinking it.
  • Recharging: One other way to refresh the focus-manna is to recharge by de-focussing. One may go for a walk or focus on a more mundane task between high points of productivity to recharge.
  • Muscle Focus: Coding is a sedentary job in most cases. Some may have a standing desk set up to be able to stand while they work. Nonetheless, in almost all cases, we can say that software development lacks any physical exertion. It is important to balance the mental stress endured during programming with a physical activity like biking or running or playing a sport.


The Clean Coder makes an excellent case for a programmer right out of school or with a limited experience to become a software engineer. A professional is in a pursuit of honing her skills while providing great values to her professional relations including employers, employees, business partners, colleagues, and herself.

Saturday, June 4, 2016

Scrum: The Art of Doing Twice the Work in Half the Time

Sutherland, Jeff, & Sutherland, J. J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time. New York, NY: Crown Publishing Group.


The author, Jeff Sutherland, along with Ken Schwaber conceived Scrum as a method of improving productivity in software development teams in the early 90s. Coming from the horse's mouth, one gets an insight into the history behind Scrum and how the author evolved the process with every project he worked on or consulted for. One also gets to view the process through Sutherland's eyes as he applies that to every project. He provides ample anecdotes to supplement his arguments towards using Scrum as the process of choice not just in software development but also in other engineering as well as non-engineering domains.

That said, it also brings about a bit of a confirmation bias of Sutherland regarding the efficacy of Scrum. Through the reading of the book, one desires counterpoints in order to balance the arguments either against Scrum or for an alternative process which may prove comparable to Scrum in advantages.

This book explains very well how Scrum may be used in an organization and will be well received by anyone who wants to understand the process and how to implement it.

Valuable Insights

There are a number of valuable take-aways from the book. It may, however, be unwise to select a few and ignore others. One thing the authors insists on is view Scrum as an ecosystem in its entirety. There may be some wiggle room but what stands against the principle values of Scrum is to cherry-pick some items while dropping the rest. Some in the industry call this "Scrum-but" which gives the team an illusion of having Scrum while maiming the process. 

Regardless, I would pick the following lessons I learned which were valuable, while being conscious of the the context in which they exist.

Don't Hate the Player, Hate the Game 

[Page 63 | Teams]

One of the major notable experiences of working with teams in my career has been when things go wrong with a product that may be perceived as critical to catastrophic. This is a time when one may observe various reactions from the team members which may range from defensive behavior to pointing fingers at another team member for a fault. In my experience, this has been extremely unproductive and lowers the morale of the entire team. Very rarely, team members would leave the blame-game aside and focus on the problem and finding a solution.

Sutherland describes in great detail citing studies regarding human behavior as to how humans perceive themselves as well as other people. Humans perceive their own decisions to be a product of the environment and how they have been affected by it. However, they attribute far more agency to other people while describing others' decisions. This explains how one defends oneself in a challenging situation while attributing malicious intent or misbehavior to others.

Scrum is designed to change this. What one must look at is how to solve the problem by amending the system. Scrum describes collective ownership of problems as opposed to finding single points of failures especially with individuals. Bad behavior must be disincentivized rather than demoralizing teams.

Do One Thing at a Time

[Page 88 | Waste Is a Crime]

This point resonates well with me. In most corporate cultures, multitasking is rewarded and is seen as a positive trait in an employee. However, numerous studies have shown that multitasking reduces the performance of the employees in individual tasks. The author of one such study is quoted in the book. David Sanbonmatsu, the author of the study, concludes that people do not multitask because they are good at it but rather because they cannot focus on a single task at a time.

Multitasking is actually detrimental to productivity. I have personally experienced this while working on multiple projects at the same time, or while being involved in development while providing support to the client. My own way of circumventing this is to make people aware what I currently work on so that if there are non-critical interruptions, they can be delayed until I reach a breaking point.

A Leader Isn't a Boss

[Page 176 | Priorities]

While describing the role of a product owner in Scrum teams, Sutherland emphasizes on how an individual's responsibility on a project should not be dependent on authority. Each individual must be given autonomy towards building a better collaborative solution. Leadership does not imply authority; it is better described by being knowledgeable and a servant-leader.

He emphasizes how all members in a team must have equal authority in spite of having two members who have specific roles unlike others. The Scrum Master behaves as the facilitator and knows the "how" of the product. The Product Owner is the one who knows more about the users and hence can describe the "what". The product owner may provide information as to what the customer wants. The scrum master is responsible for the team in determining how it will be achieved. The team members. however will have autonomy over the decisions of what work can be achieved.


While working towards a course in my graduate studies, I had done a preliminary research on how Agile processes are closely related to the culture of the organization. You may find the paper surveys here.

Scrum is very similar to Agile in that respect. (Some may categorize Scrum under Agile but Sutherland has certain reservations.) Scrum has to be inculcated in the company's culture for it to work. Many a projects have failed due the inevitable "Scrum-but" because of resistance to radical change. However, one must take the leap of faith to make Scrum successful.