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.

http://www.amazon.com/Things-Every-Software-Architect-Should/dp/059652269X


Introduction 

"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.

https://sites.google.com/site/unclebobconsultingllc/books
http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073/


Introduction 

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.


Focus-Manna

[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.

Conclusion

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.

https://www.scruminc.com/new-scrum-the-book/


Introduction 

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.


Conclusion

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.

Wednesday, November 20, 2013

Software Architecture Patterns: MVC

Long since I have updated here, I went through a number of experiences to land up in developing within the Android platform. Being pushed out of my comfort zone of server-side and database development, it is a fresh adventure by itself in developing mobile applications. Away from my usual rants about software engineering, I would like to be a bit more specific about a topic.

Software architecture can be defined in a number of ways. The software engineering institute has compiled the modern as well as the classical definitions of software architecture.

To be concise, software architecture is a set of models which define the highest level of system abstraction. This may begin with understanding the qualities of the required system and the tactics that enable those qualities. The summed up architecture document will consist of static views such as the Module Layer View or dynamic views such as the Component Connector View. However, somewhere between the requirement modeling and the views exist architecture patterns.

According to Bass et al. in Software Architecture in Practice, an architecture pattern is a description of element and relation types together with a set of constraints on how they may be used. A common example of an architectural pattern is the client-server pattern. Client and Server are two element types  and the communication between them is dictated by a protocol.

One of the most commonly used pattern is the Model-View-Controller (MVC) pattern. Consisting of 3 elements: the Model (the data element), the View (the user-facing element) and the Controller (the element responsible for user interaction). This arrangement of elements helps in isolating functionalities within the elements.
MVC with an active model - Wikipedia

The Controller forms the backbone of the system where it collects information from the user, manipulates the model and returns an updated view back to the user.

The Model can be implemented as active or passive. An active model updates the view on any change that occurs within it. A passive model, however, expects the controller to generate the view based on the changes made to the model.

The View is nothing but the user-facing element which can be described as the output to the user.

A 2008 blog describes the benefits of using this and which of the gang of four (GoF) design patterns fit into this architecture pattern. http://blog.iandavis.com/2008/12/09/what-are-the-benefits-of-mvc/

The MVC pattern has been quite popular with web applications especially within the JavaEE (previously J2EE) framework and in the .Net framework. There have been purely front-end MVC pattern modifications that were used in javascript based frameworks such as Backbone.js. However, with the Android platform, there is a stark difference.

Android applications run on the user's machine. Therefore, the MVC pattern has to be implemented at the user's end. Before going to that, we might need to take a look at the structure of android applications. The entire workflow of android applications is handled by the Android.app components. (http://developer.android.com/reference/android/app/package-summary.html). There are four main components: Activity, Service, BroadcastReceiver and ContentProvider.

The Activity provides the user interface while the Service performs tasks in background. For our MVC pattern, the activity becomes the strongest contender for a controller. The model is defined by Java classes which may or may not use SQLite for persistence. The view can be defined in XML layout files. 

MVC, MVP and MVVM -Source: 

In android, the activity classes can generate the views from the layout resources depending on the user's interaction as well as the device being used. i.e. the view generated for a tablet will be different from a phone. However, the underlying controller (Activity) remains the same. Similarly, multiple activities can reuse the same layouts for displaying similar content. This satisfies the many controllers-many views condition of MVC. Also, the view being natively stateless, enables Android to support the MVC pattern extensively.

One example of the MVC pattern being used is in the github android application (https://github.com/github/android). An example of a class which behaves as the controller is the PagerActivity class (https://github.com/github/android/blob/master/app/src/main/java/com/github/mobile/ui/PagerActivity.java) which listens to the user's interaction directly and picks a view (fragment) that should be displayed. The views are defined by layout files and other xml files (pager.xml https://github.com/github/android/blob/master/app/res/layout/pager.xml) while the model is defined by the database cache (https://github.com/github/android/blob/master/app/src/main/java/com/github/mobile/persistence/DatabaseCache.java)

Many, however, consider using the MVVM pattern within Android. The Model-View-View Model pattern is similar to MVC in many ways. The main difference is that the View interacts with the user and passes the inputs to the View Model. The view in this case maintains its own state. This is common in applications which use RESTful services with a JavaScript based view. The view in that case is the HTML-JavaScript based application running in the user's browser. The View-Model is represented by the RESTful web service which is unaware of the view that accesses it. The Model is the back-end data element which is accessed by the server only. The MVVM pattern enables the system to have many different views while maintaining common control over the business logic.

Within Android, this may be implemented by extending existing UI controls, Fragments or Activity so that they can maintain their state after user input. The ViewModel in this case can be the back-end Services which will run independent of the view. The services may in turn use an SQLite database as the model. It is essential for MVVM that the ViewModel is not aware of the View. This is mostly possible with a service-oriented architecture.

To conclude, architecture patterns, much like design patterns, are used to aid commonly faced structure issues with the software. There may be many scenarios where one pattern would override another. However, any architecture pattern should be judiciously used to meet the user's requirements.

Sunday, August 19, 2012

Around the world, over the years...

I would like to make it clear that my intentions are to advocate software engineering through this blog. Having worked for about 3 years under the title of 'Software Engineer', I realized that it is a little more than just programming. However what I did was mostly programming. On the other hand, I have been working since 5 months using the title "Web Programmer" while most of what I was doing should be considered software engineering. I have been involved in planning, requirements elicitation, process engineering, architecture, data migration, database design, user interface design, and also programming (in a language I had very little prior experience in: remember learnability!). I smirk at the irony.

Around the world, over the years...

It has been over two months since my last update. Yeah, I know that I say that every time I post something new. This time, I decided that I would rest it out and see what other bloggers have to say about software engineering. (I despise using the word 'blogosphere', a quick xkcd comic for that: http://xkcd.com/428/)

To begin, I read a blog post by Matthew W. Johnson titled "Engineering Icons, not Programming": http://imagine.kicbak.com/blog/?p=193 . I found that he made the same points as I made when I started this blog. Matthew begins to compare software engineering to civil engineering and brings in a bridge analogy. This made me question that who would make a better software engineer: A computer scientist or an engineer in another field? Understanding the facts that a regular engineer will be familiar with the general concepts of engineering and would apply them to his or her field while a computer scientist will be an expert in understanding computers and software programs. In fact, I have met a few people with no formal programming background become better software engineers than those who do. This might be a question for debate.

Another article which I found interesting was by Steve McConnell (author of various textbooks on software development and its aspects) written way back in 2004. http://www.stevemcconnell.com/psd/04-senotcs.htm . This was particularly interesting to me because McConnell would ask candidates questions related to software engineering during recruitment. He further goes on to explain how software engineering should evolve out of just plain development. To add to that, there are other project objectives that should be met. 

I would like to find counter arguments to software engineering which may bring about a healthy discussion. However, till then, I will try to update about more of the nuances of software engineering.

Cheers!


Sunday, June 3, 2012

Learn to adapt and adapt to learn


Adapt or perish, now as ever, is nature's inexorable imperative. -H G Wells

I have been away for a while: had a lot of coursework to complete and I am finally out of it unscathed. Hi everyone, welcome back. As usual, I will begin my rants with the disconnect between the job market and the definition of a software engineer.

Recently, I received a call from a company (which I do not recall applying to) asking me "In which technology are you a software engineer?"

It is the same as asking an automobile engineer, "In which type of vehicle engine are you an automobile engineer?" Specialization, you say? Not really. Although automobile engines do not evolve as fast as programming languages, an engineer must be ready for all. (S)he is the one who should make the decision regarding which is most suitable.

It basically undermines the factor of learnability within the engineer. Is it not possible that an engineer learn about a new technology and implement it? Hath not an engineer brains?
I got carried away by a bit of Shakespeare there.

However, the point I am trying to make is this: The technology is disposable. Especially in software development, where they get outdated really fast, we need people who not only have development skills  but at the same time, engineering and reengineering skills along with learnability of new technologies.

One common example of outdated technology is that of the Enterprise Java Beans or EJBs. It was (and still is) a server-side managed component architecture for enterprise applications (http://www.oracle.com/technetwork/java/javaee/ejb/index.html). Till about 2008, EJB was a highly demanded skill for "software engineers". However, it didn't take much time to die out and one would hardly see any new positions requiring knowledge of EJBs. Soon people realized that EJBs were not practical for real world applications and EJBs went out faster than lightning.

So, what happened to the knowledge gained by people who were experts in EJBs? Panic and rushing towards learning the next hot technology? If we learn by experience, we must note that adabtability and learnability should be focused on by companies.

A software engineer will provide that. One of the things that a software engineer does over a computer scientist is evaluate tools. There should be enough reasons to select a particular language and then develop in it. The focus should move away from coding and towards software development.

In fact, IEEE Computer Society's Certified Software Development Professional Certification Program (CSDP: http://www.computer.org/portal/web/certification/csdp) has the following elements:
  1. Business practices and engineering economics
  2. Requirements
  3. Design
  4. Construction
  5. Testing
  6. Maintenance
  7. Configuration Management
  8. Engineering Management
  9. Engineering Process
  10. Tools and Methods
  11. Quality
Out of 11 elements, just one element (Construction) deals with programming. Even there, it is elementary to select the appropriate language or technology before development.

Adaptability and Learnability are two important virtues of a true (software) engineer.

Cheers!

Monday, April 2, 2012

Non Functional Requirements are People too!

I started writing this blog in order to explain what software engineering is. I have noticed that most people use the words "software engineer" to describe a person who is basically a programmer. Unfortunately, that is a misguided definition of software engineer. I have attempted to clear that fog in my previous post. However, no matter what definition is used, what is it that we really need? A software engineer or a programmer?

This post, however, will take a tangent into one aspect of Software Engineering: Requirements Engineering. You can learn more about requirements engineering here - http://en.wikipedia.org/wiki/Requirements_engineering

Requirements can be divided into two broad categories: functional and non-functional. Functional requirements are those details which form the basis of the software being built. This consists of the main reasons why the particular product is being developed. As an example, one of the functional requirements of the Amazon Kindle reader is to open e-books. Another one would be to display the pages in the book.

Non functional requirements are those properties required from the software product which the functional requirements to execute smoothly. These do not form the core requirements of the product but are essential to the performance. With the example of the Kindle, we can say that displaying the pages at different resolutions clearly is a non-functional requirement.

If we can recall the chart from my previous post, functional and non-functional requirements can be mapped as verticals and horizontals respectively. This is a similar diagram for an e-book reader:






I have observed this general notion: People automatically assume "Non-Functional Requirements" as "Non Requirements". We conveniently drop the word "functional" and treat NFRs (Non-Functional Requirements) as trivial elements.

These do not affect the business logic of the software directly. These do not form the core functionality of the application. So, we assume them to be unimportant. DANGEROUS!

I would like to emphasize that NFRs are very important to the system being developed. In fact, in some cases, they are more important than the functional requirements themselves.
Consider a banking application. If we do not provide adequate security, citing that security is non-functional, we might as well go bankrupt. Many argue that in this case, security is a functional requirement. However, I maintain that the main requirements from the bank are to store one's monetary assets and enable transactions on those assets. Having them do that securely is an extremely important, yet non-functional requirement.

I think that I have repeated myself enough on this. However, I would like to summarize that the importance of the requirement is not evident from the categories of functional or non-functional. This depends upon the nature of the product and the priorities set by the software engineer. Security is generally an important requirement from most products (esp. on the internet). However, security is a non-functional requirement in most cases.

NFRs are people too!