Learn Software Development

Providing enough time and infrastructure for people to discuss and resolve items ..

ashish — Fri, 18 May 2012 20:08:57 +0000

This seems like a very odd item to write a software post about. However, this is based on a lot of experience that I have seen over the years, and also discussed with many other people (those that have seen problems where there was not enough infrastructure, and other cases where there was enough of this infrastructure). Consider a case where a company is running a traditional software development unit, where the development team runs into challenges often enough and needs to do a fair amount of thinking to resolve issues and work through complicated design and architectural solutions.
However, it is not as easy as it sounds. This is not routine work of software maintenance; in a lot of cases nowadays where people work on complicated stuff and try to be as innovative as possible, there is the need to do a lot of new stuff. New stuff means that you need some real good developers, those who can think of new solutions, who can work the things out. However, for this kind of work, you need people who do a lot of discussion with each other, trying out new stuff, working through architectural problems and looking at alternate solutions.
Now, what does this need ? I already mentioned the need for some people for the development team, but there are other infrastructural stuff that is needed to ensure that the developers have the right environment. A big deal for this is the need for place to discuss things, some good recreation stuff (such as games and the like), and so on. In this post, the focus is on the discussion. One empirical fact was that if you go to most places where developers are present and there are tough solutions, you will find a lot of the boards having discussions and architectural alternatives being discussed. Having enough whiteboards near the developer community enables these discussions to happen, also resulting in solutions and decisions.
Not having this sort of infrastructure in place inhibits the development team from these sort of discussions among the team, and does play a role in a resulting slowdown of the pace of solutions of issues. I have seen organizations where both of these situations were present, and there is an effect of having these infrastructure in place. I would recommend that organizations that have a lot of development work have enough infrastructure in place to support the development team.

What happens when your product is not stable close to release date ? – Part 6

ashish — Tue, 15 May 2012 19:56:46 +0000

This is a series of short posts about the scenario where a product that decides the future of the company is being released, and how it can be difficult to make a decision about release vs. delay when there are suspicions that the quality of the product may not be as desired. In the previous post (bug closure during the end game), I was talking about the bug closure rate near the end, and how the pressure near the end can be problematic for the people in charge of approving or deferring bugs.
In this post, I will talk about a horror situation where the management is not connected with the team (not connected enough to know about the current situation) and the pressure forces management to take hard steps which eventually blows up in their face, enough to shake their own careers. This is not a fictional situation, it has happened with several companies, and there are other cases where it has almost come to this, but the senior management has managed to turn things around and prevent the situation from going out of control.
Consider a case where the product that is going to be released is very significant for the company and there is a huge amount of market, stakeholder and executive pressure. The career of the key senior management stakeholders can depend on how well the product release has been handled, whether they have shown the necessary guidance and overall management to take their entire team along, and similar goals. So what happens when the pressure forces them into such a place that they get so committed to the release of the software, enough to ignore the pressures of the teams working on the software, and are only exposed when whistle-blowers in the team go right to the top to make their point known that the software is not yet ready for release.
An example of this happened a few years back in a large company (I will not take names deliberately, since the idea is to show what happened rather than only point out a specific example). The senior management felt that they had a good control of what was happening, and the pressure on them to ensure that the release happened on schedule was enough that they forgot the part about the release also being of good quality. So, at some point you had a situation where many members of the team had huge issues with some of the open items that were potential customer problems, while the executives felt that the team did not have the big picture, and these issues would be closed in time (and that some of them could be ignored since they impacted a minor section of the consumers).
This continued for some time, with the interaction between the senior managers and the more vocal of the team members not really reaching a conclusion, and the team members started feeling that their valid concerns were not being addressed (and since they had been with the team for many years, they were also deemed as significant stakeholders). And then the matter got raised to the CEO. This resulted in the senior managers (or rather, the key senior manager) being let got after some time because of the huge amount of communications gaps that were showing up, and because the situation that was fraught with huge risk was not handled in a way that seemed like the logical way to proceed.

What happens when your product is not stable close to release date ? – Part 5

ashish — Thu, 10 May 2012 20:47:07 +0000

This is a series of posts which talk about decision time when a major product such as Microsoft Office is near release, and the product is not yet stable (which means that the team that should sign off the release is uncomfortable with the current quality levels of the application). The release being on schedule is fairly important for the company because of the strategic, and revenue reasons, and delaying it will have an impact. The previous post on this topic (getting information up the management chain) talked about how there should be a process whereby the team does frequent status reviews, keeping upto date with their issues and risks, including the high end ones; and the ones that are more risky are bumped upto the chain of senior management with mitigation strategies and concerns. In addition, periodic status reports that can be summarised to showcase the important issues let senior managers get a good grip on issues that are not going away and which can cause huge amounts of problems.
One of the biggest problems that can be seen is about the rate of bug closure. During the development cycle, there is a certain pattern in terms of defect find rates and defect closure rates, with the expectation that as the team nears the end of the cycle, the rate of defect closure is better than the rate of defect creation. When this does not happen, things get tricky for the development team, since if the number of open defects do not come down, it makes it very difficult to trend down to the point where it is safe in terms of quality to start seeing the application as ready for release. At such times, a pressure to release the product sees the team getting ready to release the product even when they feel that it is not fully ready. In addition, if the number of new defects being found is not declining, it means that the application is still not ready in terms of quality to be released, and no amount of pressure will make the product ready for release. What pressure will do is to make it difficult for team members to admit that the product is not suitable for release (you will need somebody very determined and honest to make the point in front of the management team to argue about the product not being fully ready as yet).
All of these data in terms of the number of defects being filed, the severity of defects being files, the defect closure rate, any abnormal defect deferral rate can all be determined through defect metrics tracking, and it is very important that the team maintains such metrics, since that provides a lot of data that helps in determining whether the quality level of the product is good, or whether it is getting better, or whether there is still some time to go before the product could be good enough to be released.

Read this book for some more advice in this area: Judgement Calls: Making Good Decisions in Difficult Situations –

More about this in the next post (serious communication problems) ..

What happens when your product is not stable close to release date ? – Part 4

ashish — Thu, 10 May 2012 15:24:28 +0000

In this series, I have been writing about the problems that arise when a product (deemed very significant for the organization) are near release. In the last post (deferral of bugs near the release date), I talked about the rate of deferral of bugs in the end game, and how this time of the schedule means that bugs are evaluated much more carefully to review whether these need to be fixed or can be deferred (and there is a lot of review to ensure that bugs are not let through which could cause a risk to the release).
In this post, I will talk more about some of the measures that management should be having in the organization in order to ensure that there are no sudden surprises and information moves up the organization structure to the management chain about the current status over the period of time. If such a process is not in place, then the organization will keep on running into cases where they don’t know about problems that may be causing a risk to the release schedule of the application, and will be hit with those problems when they least expect it. And you certainly don’t want to be in such a position where the senior managers don’t know about potential problems and suddenly come to know about it. In such cases, the responses that you get from the management chain may be of managers trying to get a quick handle on the situation and how to address these problems, which is not at all a nice position for the team to be in.
So how do you prevent the problems that has been outlined in the previous post ? Well, the first and most important way is to ensure that there is a process for status discussions up and down the management chain to the level of the team involved in the actual execution of the application development. In addition, there should be a clear way for the managers involved in the chain of command to be able to highlight risk points and do this in such a way that more serious issues get moved up quickly up to the level of senior management. This starts right at the team level. The team should be having a regular status discussion where the current status of the application development (including the dependencies) is discussed within the management structure of the team and if there are issues that are deemed significant and could imperil the release schedule of the team, those should be raised up the team manager upto the next level of the structure, along with a background on the issue and potential mitigation steps. If there are no mitigation steps or is out of the control of the team (with external dependencies, or other issues such as resources), these also need to be emphasized along with suggested steps about what is needed to be done.
In addition to this, the team should be sending out a regular status report that is highlighted to senior management with a summary of the top issues and whether the team feels that there are issues that could cause problems. A combination of these steps at the various parts of the application could ensure that senior management knows about the issues and is not surprised when these pop up.

Read this book for some more advice in this area: Judgement Calls: Making Good Decisions in Difficult Situations –

What happens when your product is not stable close to release date ? – Part 3

ashish — Wed, 09 May 2012 20:16:20 +0000

In the previous post in this series (Getting advice from the team about status), I talked about the importance of making sure that feedback from the team is not crushed, and that people are not put in a position where they feel that they are doing something against the organization when they report status that is not comfortable, or where they say that according to them, the product is not in a good position.
Now, for a large product, there will be several layers of organization that will be working on the product, and it is good to remember that all of them have some fact and some information that may be relevant or may not be. In fact, in today’s world where user forums are a quick way for a problem to be reported and then more me-too’s to quickly join in through social networking, it is very hard to determine which issue is a huge problem and which is the one that can be safely ignored. It may seem strange to those outside the industry, but it is very much possible that a defect in the program that may be irritating to that specific user or cause some problems may not be something that the team considered worthy of fixing.
The next few lines will not be about the decision making, just more about what goes on as the team nears the release date. As the product gets closer to release, and the situation is not such that there is absolutely no chance of release (if the team is indeed in such a bad situation, it will be visible to everybody and decision making will be much easier), the status with regard to defects in the application will become much more complicated. It is a known part of the software development process that when the team gets near the release date, selecting which bugs will get fixed and which ones will not be fixed (or will be deferred from the current release) gets tricky. Closer to the release date, the problems associated with enhanced risk for every defect that is fixed become critical. What this means is that unless the defect is evaluated to be sure that this is needed to be fixed, and that the actual fix will not end up destabilizing something else, the team may well decide that the problems sought to be taken away by fixing the bug are not worth the risk, and a larger proportion of bugs will be deferred (and not fixed).
Deciding which of these bugs need to be fixed and which one needs to be deferred is critical. However, this should be an independent decision by the Bug review committee having the Product Management representative, and (to emphasize), it should not be under enormous pressure to defer bugs in order to meet the schedule. What this means is that it can happen easily enough that the management team relays the pressure down to the team that it needs to increase the rate at which bugs are being deferred in order to meet the schedule. This tactic runs the risk of letting through such bugs that can be bad for specific sets of users and bring about a lot of condemnation on user forums and among user groups.

Read this book for some more advice in this area: Judgement Calls: Making Good Decisions in Difficult Situations –

More about this in the next post (link) ..