Code Review – How to get it right?

Code quality is one of the often talked about issue in a project status meeting. The magnitude of this issue will be bigger in case of maintenance products, where end users are encountering defects. While all the members of the project team very well know that code review if done well during the build phase could reduce the code quality issues by a significant percentage. The design and build process manual clearly calls it out that code review is an exit criteria for the code to move on to QA for testing. But still this issue surfaces every now and then.  

The question that comes up is whether code review was done at all or done just for the sake of process compliance. The possible reasons for reluctance among the developers to do a peer review are: Lack of reviewing skills, using the review finding against the developer for reviewer's personal advantage, inferiority complex of the developer. The other most common reason cited attributed by developers is lack of time. 

As all of us are very clear on the benefits that the code review bring on the table, let us not try to list out and discuss about the benefits. Let us attempt to list down the required skills of a code reviewer.

Subject matter (Domain) expertise:  Though most developers are not expected to be domain experts, this skill will certainly be required if the code review is expected to prevent functional defects getting slipped into the next phase. The very fact that the developers need not have domain expertise could possibly mean that the developer might have not understood the requirement as it was intended to be resulting in injection of defects. A mis-interpretation of the requirements could result in a functional defect and there is a chance to spot it if the reviewer posses the domain expertise. Some of the production defects could be unique and may not be reproducible and in such case, code review is the recourse to trouble shoot. This if done well during the build phase, could have prevented such defects surfacing in production at a later stage.

Technical Skills: The reviewer should be an expert in the technology and the programming language used. In software programming, code could be written in innumerable ways for a given requirement. However, given the standards and practices the team is expected to follow, the various quality attributes identified for the project and the goals set for the specific review, the reviewer should possess appropriate level of knowledge to spot problem areas. It is important for the reviewer to know the internal subsystems and the inter dependencies on various local and external computing resources.

Positive Attitude: This is a very important skill for the reviewer and the reviewer should never use the review findings against the developer as an individual. The issues should be considered as a team issue. The Reviewer should acknowledge the capabilities of the developer and the developer may have valid reasons for having written code in a particular way. At the end of the review, it would be a good idea to discuss the summary of the findings with the entire team, as some findings could be good learning for other team members. The organizational standards and practices should also be revisited and revised if necessary based on the nature of the findings. This may also result in identification of certain training needs for the team.

Team Skills: Both developer and the reviewer should have the common objective of producing quality code out of the build phase and they must work as a team to achieve best results. If not, the code review may happen just for name sake or may lead to personality issues which in turn would affect the project deliverable.

Attention to Details: This is an important skill a reviewer should possess to carry out effective reviews. Typically it is human to miss certain blocks of code as parts of it may appear to be correct. Unit testing is not a substitute for code review. The reviewer should with respect to each line of code, ask questions like, what if this statement fails to execute, if there is any other best way to achieve the same action, whether this could lead to potential performance issue, whether this statement may require more system resources, like Memory, CPU time, etc.

Knowledge on Tools: In addition to the above, code reviews with certain specific goals will require knowledge and expertise on appropriate debugging and diagnostic tools.

One of the key metrics in the Software Engineering space is defect injection ratio. This helps to identify the phase that has injected most number of defects. Many times, the stake holders think that it is the developers who inject defects into the delivered software. The reality however may not be completely true as much number of defects get injected in the requirements and design phase also. However, code review when rightly used, helps the development team not only to keep the defect injected in the build phase under control, but also not let the requirements / design phase defects slip into the next phase. 

Solution Architect - Understanding the role

I keep getting questions from some of my friends, as to what the role Solution Architecture is all about and will they be a fit for that role. For the benefit of every one out there, I thought of putting together my thoughts on the role of Solution Architect. Let us first examine what is expected out of this role and then look at the skills needed to be in this role.

As the title indicates very well, the role is expected to bring in solution to varying business problems, most which could be a product or project by itself. But, as you know, it is always a challenge to come up with a best solution due to it being intangible and that there are many quality attributes which are not completely identified and specified. There would be lots of missing links in the areas of business domain, choice of technology, hardware components, business processes, future domain and technology trends, etc  which the Solution Architect should be able to connect and come up with best solution that could last longer, so that the organization reaps the return on investing in the solution.

Some of the key characteristics of a best Software Solution are:

Longivity: While the solution must solve the current business problem, it should also be reliable, usable, secure and also future proof. This means that the solution Architect should consider the industry and technology trends that could have an impact on the problem / solution in the near and longer term.

Trade off: The challenge with the various mostly unspecified quality attributes is that they are interdependent. And meeting one such attributes may most likely mean compromising on another. Obviously, a lot of trade off has to happen between various quality attributes and such trade off should be justifiable in the context of perceived benefits for the organization. For instance, performance may have to be compromised to achieve better security. The tradeoffs have to be carefully made after considering various factors, like the risk appetite of the organization, target users of the solution, the technology platform, current IT investments of the organization, etc.

Implementation view: It is important that the solution should be devised with the intended deployment view into consideration. Without that, it could so happen that the solution as designed and built may call for massive changes to the infrastructure investments, which could be a total surprise for stakeholders. Such surprises emerging towards the close line of the project could increase the cost by manifolds or delay the project further.

The above is not the exhaustive list. There are many other factors that will have to be given due consideration before coming up with the best solution. Above all, the solution architect should be able to see that the solution is successfully implemented and put into use. That means, a lot of work in terms of convincing the stakeholders as to why this solution and not an alternative, hand-holding the design and development team and also to some extent the end users to have it implemented the same way it was intended.

With all the above, let us now try to identify the essential skills of an aspiring Solution Architect:

Domain skills: A thorough understanding of the business domain is required to first understand the problem better and second to know the potential future needs that may emerge along the same lines of the problem space. It is also important that the person has the ability to learn things fast, as in most cases, there won’t be lead time for him to gain appropriate business skills. That means, the Solution Architect should also be a Business Analyst.

Technical skills: A thorough understanding on the technology currently in use in the organization, the technology currently in use in similar industry domain and the emerging future technology trends. This knowledge is essential to ensure that the solution does not become obsolete soon and that the organization is in a position to be ahead of completion in terms of IT enabled capabilities. At the same time, applying a new technology early in its evolution has its own issues and it is always better to wait for the technology to evolve and mature as more and more organizations adopt the same. It is important for a Solution Architect to closely follow technology trends and gather enough knowledge to understand what could be the best fit for solving various business problems on hand. He should have enough understanding of the technology chosen, so that his team (mostly himself) comes up with a prototype to establish that the solution really solves the problem. However, as the solution goes further down the implementation lane, the Solution Architect should be able to demonstrate hands on skills, so that he could command expertise and be the go to person for resolution of issues.

Team skills: Though mostly the Solution Architect will be an individual performer, some organizations may have dedicated teams to assist the Architects. Even in case of Architects acting as individual performers, the solution is implemented by a project team. So, the Solution Architect needs to be a team player and should with his domain and technical expertise, lead the team by example.

Process / Project Management Skills: Needless to say that the Solution Architects have to have the Project Management skills too, as one may have to manage the pre-solution activities as a project. For the purpose, he has to be familiar with the processes as well.

That means, the Solution Architect should be an all rounder with moderate to expert level skills in all the areas.  On top of these skills, one has to understand that solutioning is not just a science, but also an art, which is mastered with years of experience over as many projects and years involving various technologies and domains.

There could be different views on this and comments or opinions are welcome. 

Electronic Service Delivery Bill

It is good to note that electronic delivery of public services is proposed to be mandated in India. The Ministry of Information Technology has proposed a draft Electronic Service Delivery Bill, as per which, every competent authority of the appropriate government shall publish a schedule for delivering public services in electronic mode. It also requires that the all public services in India should be delivered in electronic mode within 5 years from the date of commencement of this bill. The bill also provides for extension of the term by another 3 years, provided it is supported by valid reasons. That means, in eight years from now, all public services in India will be delivered online. The draft bill can be downloaded from the Ministry of Information Technology website.

The bill is likely to be placed before Cabinet soon. Check out this news brief on Business Line.

BYOD – Yet another challenge for IT heads

For those, who are not familiar with the term BYOD, it stands for “Bring Your Own Device” and use it to achieve your work goals, be it within the company or anywhere else. A simple example for this is when an employee uses his own iPad to access his corporate emails, or use any other wi-fi enabled device to connect to corporate wi-fi network and use it to perform certain work related tasks. This has been in practice with the education and training companies, where the students / participants are expected to use their own devices, subject to meeting of the required minimal hardware and software specifications. Thanks to the last recession the recent explosion of the smart personal gadgets, companies are increasingly considering allowing this. 

The factors that drive the BYOD amongst corporate are:

1.  Increased Productivity - Employees are expected to be happy working on their favourite stuff and in turn that is likely to bring in increased productivity.
2. Better Mobility – Organizations with mobile workforce, who typically work on the move, feel that BYOD could offer better mobility and flexibility.
3. Cost Savings – Though this may not be a real benefit, as organizations may end up spending considerably on mitigating the risks that BYOD brings on board, this is considered as a factor driving the increased adoption.
4. Influence from senior executives – Typically if a senior executive buys a latest gadget and then using it in the workplace to do their work.
5. Decreasing client installs – With increased adoption of Cloud based applications, all that a user need to access the enterprise application is a compatible web browser and this favours BYOD.

Certainly BYOD brings on board a lot of challenges to the IT department and here are some of the key challenges:

1. Support – The IT department have to start supporting varying make and models of smart gadgets running different operating systems and web browsers. Unless the IT department comes up with the list of gadgets that they can support, it could soon be a nightmare.
2. Licensing – If there are certain third party components to be installed on the smart devices, then it is better to have the licensing terms of the component vendor verified, as some vendors may impose restrictions in installing such components on devices other than those owned by the organization.
3. Network and Application Security – When employees use the organization provided devices, they are appropriately hardened in line with the security policies of the organization. But in case of BYOD, the employees for sure would not like to have their devices hardened for work use, instead they would like to be the administrators of their own device and play with it in whatever way they want. On the other hand, employees may even go ahead and install more and more mobile apps of their choice, some of which could even be malware.
4. Data Security – Whatever data that is cached or stored on the gadgets, as the devices are used for work are subject to be easily compromised.

For sure, this is yet another challenge that the IT managers should be ready to face soon, if not now.