Subscribe by Email

Saturday, May 23, 2015

Need for doing a legal audit to detect all 3rd party instances

A lot of people do not even know about this concept ? What is a Legal Audit (or a similar name that may be followed by different software organizations). However, most project / program managers would know about using components from many different sources. And you would also have heard about patent disputes, where companies challenge each other about the software that they have written, and whether one of them was entitled to damages from the other for using a certain code over which the other claimed ownership (actually a patent is about the principle or concept or a specific feature, but you get the general idea).
How does this fit into the idea of something called a Legal Audit ? Patience.
Let me take a real life principle. In our team during the course of a product development cycle, the team is informed at the beginning of the cycle that they will not use any component from outside without speaking to their manager. However, during the middle of the cycle, I was speaking to the team about this (as a repeat) and later one of the team members approached me. It turned out that he was looking for an efficient XML parser and searched for an external component that would help him in this; he found something on the internet, downloaded and used it. Seems fine, after all, a lot of people might do this.
The problem was, we are living in a world where we need to respect the rights and copyrights of others, if we want others to respect our software. Our software has a global market of $40 million, and nobody would welcome a case against us for unlawful usage of an external component. It could be that we were fine with using this component, but nobody had done that kind of check. We looked at the component, and found that it had a license that was never going to be allowed for usage. The license wanted $1 for every customer usage of the software where this component was going to be installed, and if you think that we were ready to pay out tens of thousands of dollars for using such a component, I have nothing to say.
The Legal Audit is a way to do a scan of the software code to ensure that all the external components that are being used in the software are known, and the licenses are all approved towards this end. For product development where the product has been going through multiple versions, a lot of the components would have been in regular use over the years, and these can be quickly discounted. Most organizations would have a way to do this process in a way that minimizes the effort required.
Doing this process is essential, and in most cases, would require consultation with some software engineer or manager as well as with a legal expert (to sign off the final license agreements and to certify that the overall set of licenses used in the software are fine from the perspective of the organization).
And the Legal Audit can only be complete when the writing of new software is complete, since only then can it be sure that there is no further new code going to be written.

Friday, May 22, 2015

Getting statistics of build success rates and reasons for failure

During a regular product development cycle, the Daily Build is one of the most important items that have to successfully happen. If the Daily Build has failed, or is only partly successful, or even needs only some partial work to do before using, it can be a source of irritation for the development team. Even though they can use the previous build, the fixes from the previous day would not be there, which is an irritant. And if such build failures happen from time to time, the irritation can build up and cause doubts about whether the daily build can be depended upon to happen consistently.
There can always be reasons for the daily build to have failed - reasons could be some dependency problem that a developer did not verify before checking in their fix, or some hardware failure, or problems with some recent patch (once we had a case where a new Operating System patch was in turn causing the Virus Scan engine to not release one of the build process files, and it was a pain to diagnose that problem), or some other human failure on the part of the build engineer.
If the build failure happens on a periodic basis, status meetings are sure to resonate with worries about how the frequent build failures are impacting the ability of the team in terms of reduced productivity (and this worry can sometimes be enhanced from the actual levels, but it is not easy to make this statement in the status meeting). Further, it is an imperative that each and every build failure be monitored to ensure that the same reason for build failure does not happen again (or there better be a very good reason why the same reason could cause a build failure again).
The way to do this is a simple process. The build engineer can easily setup a process whereby the statistics for every day's build success are tabulated, and since it is an assumption that the reasons for the build failure or delay would have been monitored by the build engineer, these can be added to the stats for every case where there has been such an occurrence.
On a periodic basis, such a report should be sent out to all the people concerned with the build or who have been nominated by the team to track the build (we had created an email alias for the build issues and whoever wanted could become a member of the build alias, and this build report would be sent to this email alias). There were advantages of having such a status:
- It ensured that everybody had accurate figures about the number of times the build was broken or was delayed
- It pointed out issues that could be regular or cause repeated build failures and how they were handled. This one area of the report was a great confidence-builder
- We were able to monitor whether there were improvements in the build success rate (and that was a reasonable expectation)
- It also pointed out cases where the development team engineers caused failures and put pressure on the development manager to tighten the ship on the development side.

Tuesday, May 19, 2015

Build acceptance - Ensuring that one person certifies the build as accepted

During the regular product development cycle, the build (typically daily) is the most important input to ensure that the process of build testing, defect fixing and incorporation of the fix into the product, and testing again continues. If the build does not come on a regular basis, defects are not available for the testing team to fix on a regular basis; and it is essential that defects get into the product at a regular basis. If not, team developers start getting out of phase with respect to files being changed during defect fixes by multiple people, and more effort needs to be spent to resolve these dependencies.
Most teams typically like to get the daily product build early in the morning, before the developers and testers are in position. Such a technique ensures that when the team arrives, the build is already available and ensures the maximum utilization of time. However, as a part of this, it is also essential that the build be ready and be fully fit, not have major defects. For this purpose, it is essential that the build be verified before it is started to be used by the team.
A lot of teams have built automated smoke tests that take the build when it is available, launch it and do a quick major tests, and if everything goes right, an email could be configured to go out to a specially setup email list which would ensure that the right people knew that the build was correct. This works in most cases, but there can be cases where there are false negatives. For example, there is a small change in UI or some other feature which was not incorporated into the smoke test, then the smoke test would give a failure, but the build could have been successful (and one can think that such a case may not happen, where the information about a change would always be built into the smoke test, it can happen and has happened).
In other cases, a person needs to evaluate whether a partly successful smoke test and see whether the new build need to be built or the existing build can be used, with some assumptions. For example, one particular feature need not be fully working, but everything else could be working. Now why would the team want to use a build where not everything was working fine. Well, because there is a cost to make a new build. Building a new build could take time, many hours in some cases, and till that time, the developers and testers would have to be using an older build, which may be fine in the early stages, but gets more problematic as you move along the schedule, since such delays in getting defects fixes in the build may increase the cost and impact.
To take such calls needs to be done by a person on the team; and this needs to be specially assigned, since such a person would need to review the build and take a call before the other team members start working on the build, which would mean that the person would need to get on the job much earlier than normal.

Saturday, May 16, 2015

Using videos to explain features to other team members

One of the most important processes during the entire product development process is to explain the features to the other members of the team. The product manager coordinates the requirements and the feature flow, the experience designer then converts these into a actual feature flow (screen by screen, and UI element by UI element), and then finally this is converted into an actual working application (whether this be a desktop or web or mobile application). Now, even though the different team members can be an integral part of all the discussions that have happened, and well aware of how the developer is delivering the software, there are still grounds where there can be discrepancies in the understanding between the developer and the tester (there was a case where I was deeply involved where the product requirements researcher and the developer had been interacting daily for the feature, and yet, after around a month, when the feature was developed and the researcher had a chance to look, the features were off by around 5%). I am not for a minute suggesting that such things can get down to 0% deviation, but we should all be doing steps that help in reducing the possibility of such deviations.
These were simple cases. There can be more complex features, where the feature work forms the background of another feature, or the feature needs to be tested by multiple testers, or the Help document writer has to write about the screen and element by element flow in the application, and needs to understand everything in detail (and not being involved since the beginning, I could understand why in many cases, the documents so produced led to frustration among the team and needed multiple iterations), and in the worst case, the testers are in a different time zone and different geography from the developer.
This is one idea that I saw a developer doing. He had figured out that these kind of problems above can be very frustrating, and even though he would be frustrated, and his development manager would back him up, there would be multiple times when he would have to explain the same screens (in a particular workflow that he done, there were many UI elements in the screen and some UI elements were dependent on the values entered in the other UI elements); he almost dreaded the explanations he would have to do to multiple people. What he ended up doing was, during the unit testing he was doing, he would have a screen recording application running and he would provide some running commentary while doing this. In the end, he would have videos that essentially ran through the entire gamut of options for the screen workflow and it required much less effort after that to make them run in an order that was relevant for somebody else trying to understand. He would also have explicitly budgeted for the time required for this, and was able to show the advantages of doing this (although there were always some developers who were against the idea altogether, maybe more of their personal feeling that they would end up spending too much time on the video part).

Thursday, May 14, 2015

Ways to improve meetings held for conflict / issue resolution

What I write below may seem like common sense, the kind of stuff that you would get if you were to sit back and think about how to do a meeting. This is even more important if you were to read my previous post (Reducing the number of meetings held) about how to make an effort to reduce the number of meetings that are held, which can suck up the time available with the development and testing teams. In addition, with the number of meetings being held being high, the continuous time that the teams need when they are in the middle of something gets interrupted and this can have an incredibly bad effect on productivity.
During the tension and stress of an ongoing software development cycle, teams need to resolve issues fast. As a result, when there is some kind of issue that need resolution, teams forget all the basic concepts of how to setup a meeting, what are the preliminary steps that need to be done before starting a meeting, and the net result is that even though conflicts are resolved or atleast progress made, the teams end up spending a large amount of individual time on these meetings; and we know the impact this has on the team productivity.
So what is to be done in the case of some conflict or issue that needs to be resolved. Even though it may seem logical to quickly call a meeting to get a solution for the issue, this method should be retained only for those issues that are of a show-stopper nature (for example, a defect that is stopping the launching of the application, or something equally similar). In most other cases, if you spent a bit of time, you would realize that an hour or so before the meeting can help make the meeting more productive. What are some of the steps that could be done before the meeting ? In the below steps, there may be multiple people who may need to be consulted depending on the steps (these could be team leads, project manager, development manager, quality manager, etc)
- For the issue, need to identify the people who are most competent in the issue and who would be able to contribute the maximum to this issue
- For these people, need to identify whether they are available or are involved in some other critical issue. If they are so heavily involved that it would not be good to get them out of whatever they are doing, then somebody else who can provide a solution or inputs would be needed to be identified.
- Next, a brief write-up about what the issue is would need to be written up, especially focusing on what the problem and if there are any elements of a possible solution; and this would need to be sent out atleast an hour or more so before the meeting.
- Before sending out these items, the meeting that needs to be setup should also make it clear as to who all is important for the meeting, and who would be optional for the meeting. What this does is to give team members a say in whether they need to come for the meeting or not. In most cases, what would happen is that team members who are on the optional list would evaluate whether they can contribute or not and decide accordingly. This atleast helps in saving time for those who decide not to come, and even those who come for the meeting are more informed, which makes for a quicker meeting and hence more saving of time. 

Ensuring the minimum number of meetings necessary ...

In software companies, if there is one item that is necessary, it is the concept of meetings. Meetings are the life blood of companies, and sometimes, one feels that the number of meetings that are held are excessive. In my experience, I have had developers and testers coming and complaining that the number of meetings that they are being invited to is so excessive that they feel the time involved for work is getting impacted. Even further, when a person is getting into the core of their work - whether it being the design of a new feature, or the solution of a difficult defect, or the execution of a difficult test case, facing a break in between is guaranteed to rankle. And there are numerous meetings where the team members (developers / testers / others) could be called for meetings, where it would seem that they are necessary.
Some of these meetings could be:
- Feature discussion meetings (numerous)
- Schedule planning meetings
- Task definition meetings and estimation
- Issue resolution meetings
- Daily / Periodic status meetings
- Add your own set of meetings here
You get the idea. It can be pretty frustrating. I have seen weeks where there were atleast 4-5 meetings per day, and even though you would think that these meetings are important, they do cause other problems. And at some point, if the people invited for these meetings start feeling that the subject of the meeting is not important for them, then you will start getting resistance in ensuring that these meetings are held.

So what is the solution ? There is no magic bullet, no quick solution I can give that will reduce the number of meetings you need to do. It requires careful planning, discussions between the respective managers (such as the project / program manager, the development manager, and the testing manager). Some of the questions that need to be asked before a meeting is set are the following (and there would be other questions that are not in the list below, it is just an indicator of the thinking that needs to happen):
1. The invitee list for the meeting needs to be evaluated. Is each person really necessary for the meeting. Can some people be marked optional, so that they can determine for themselves whether it is necessary.
2. If there are some minor issues that could be settled in a meeting, but could also be settled through a quick phone call or a quick hallway discussion, then that makes sense. In many issues, one person really needs to make a call, and the others need to just be informed. In such cases, having a meeting is really not necessary.
3. Is the issue really necessary to be discussed urgently ? What this means is, if the meeting is pushed out by a couple of days or a week, would it still be fine ? If so, then an alternate would be to postpone the meeting and see whether the issue can be resolved through phone calls or an email discussion.
4. In some meetings, the discussion is about nobody willing to take a quick call, or because there are no real solutions. In such cases, the meeting in a number of cases will fail or another meeting will need to be held. It would be better to prepare a solution or a note that clarifies issues, and then send that out. In many cases, this would be accepted by most of the people who have the authority to accept it.

Wednesday, May 6, 2015

Keeping some capacity of the superstar developers free for quick resolution

In every development team, you will always have a mix of people of different technical capabilities. This may not be for lack of trying; a person may try real hard and put in a lot of effort but may still not be able to work as quickly and as efficiently as another developer who seems to have the knack of being much more skilled. The better developer will eventually get more rewards and sail through appraisals much quicker, just as long the person also puts in the hard work, besides the skill.
Because of the skill levels of the more skilled developer, in a lot of organizations, such a person would be used for more difficult technical work and yet not one that could end up to be boring or repetitive (sounds very obvious, but it can happen that the work that is assigned is not interesting enough and i have known such a skilled developer to want to join other teams when they start feeling that the work they are doing is not really interesting).
One area in which such a developer is used is for new work, or for some new feature where there are expected to be technical challenges and is also critical for the project / schedule. In such a case, one would want the best resources on the team to be on these investigations, since the actual work on these features depend on how well the initial prototype / technical research is done. Once the initial work is done, it might be feasible to hand over the actual detailed work to other members of the team and utilize the more skilled developer for other similar projects.
However, if you want to plan for amount of risk mitigation for the project, one risk that comes up again and again is about serious defects coming up during the cycle, especially near the middle to the end of the schedule. If there is a serious defect coming up in such a phase, it gets more problematic since such a defect needs to be evaluated with a lot of care. While fixing any defect, one needs to be very careful that the fix is done completely and no other problem is caused by the fixing of the defect, and it can and most likely will happen that fixing of a defect will cause some problem (the percentage of such events is low, but not zero, and will happen).
When such serious defects are found near the middle to the end of the project cycle, one really needs to be very careful that these defects are evaluated properly, risks enumerated, and any possible complications reduced or brought down to zero. And as one advances in the schedule, the time period available to do these evaluations reduces. In such a case, it is necessary that the most skilled person in the team either looks at such defects, or reviews the work done by other developers in order to reach the same conclusion.
For this to happen, some amount of time needs to remain free for the skilled developer so that he / she can be put on such defects. Else, if the developer is working full time for some other feature (and it would be an important feature), pulling aside for defect evaluation may not be possible, or may impact the other feature negatively, which has its own impact.

Facebook activity