The managers of the team looking at reviewing processes before the start of every project / product cycle

One of the most critical factors in making a project cycle successful is the processes that are used by the team. What do processes do ? Processes define what the team is supposed to do in different circumstances, whether this be part of the regular routine work of the company, or whether this be involved with exceptional circumstances. Some of the most critical and regular processes that a team deals with and which define whether the team will be successful or not are:
- The process used by the team members for the design phase (whether this be the high level design or the low level design)
- Processes during the coding phase (code re-use, code marking and modification processes (such as commenting with the code, etc), code review process, etc)
- Processes used during the testing phase (process of filing a defect, determining whether the defect has indeed been fixed and can be closed, etc)
Like these, there are numerous processes that are used during the development project, and they play a critical role in ensuring that the work gets done efficiently, and at the same time, as desired. A team may be using processes that have evolved after a lot of experience, or could have been designed by a small set of people (for example, when we wanted to incorporate a component from a new third party vendor, we had to define a process for testing, defect logging and communication with the vendor that worked for the vendor and for us, else things can go real haywire).
When the team is doing one release after another, the processes that they are following are typically those used in the previous release project, and since people are used to these processes, it is pretty easy to follow these processes. However, it is important that the management of the team spend some time in collecting information about how well these existing processes have worked, whether there is a need of modification of some of these processes, and whether some new processes need to be added.
One of the prime examples of collecting such information is the post-mortem meeting. One of the discussion points can be the processes being used in the team, and whether the team feels that there needs to be some modifications in the process being followed, or whether there needs to be any new processes to be created (and such a discussion cannot just start in the post-mortem meeting, but the team needs to be informed that the topic of the new processes will come up in the post-mortem meeting, and that gives them more time to bring the points for the meeting; in fact, the team managers should think through some seed points for such a discussion and include this in the earlier communication, and that will encourage the team to think through this in even more detail).
But this cannot be just restricted to one meeting. If required, specific agenda groups within the team need to be formed to explore some of these processes (for example, every cycle we set up a team to discuss improvements in the coding processes, including the code review process to see what are some of the improvements that are possible and whether some of the processes are no longer applicable and need to be dropped).
The managers can also play a critical role in such a discussion. Each manager can hold a similar discussion within their teams and figure out what are some of the improvements or changes that the team is looking for. When there are processes involved with the external teams, it is important to do a discussion with the external teams to figure out tweaks with such processes as well. There is not a single step to modify such processes, it can be incremental, taking several weeks or even months, but there has to be clarity that initiating such a process of review needs to happen.

What are the characteristics of network layer?

- The network layer comes at number three in the OSI model of networking. 

- The duty of this layer is to forward and route the packets via the intermediate routers. 

- It comes with functional as well as procedural means for the transfer of data sequences with variable length from a source host to a destination host and across one or more networks. 

- During the transfer it also takes the responsibility for the maintenance of the services functions’ quality. 

There are many other functions of this layer such as:

Ø Connection-less communication: In IP, a datagram can be transmitted from one host to another without any need for the receiving host to send an acknowledgement. Protocols that are connection oriented are used on the higher levels of the OSI model.

Ø  Host addressing: Every host in the network is assigned a unique address that determines its location. A hierarchical system is what that assigns this address. These are the addresses that are known as the IP (internet protocol) addresses.

Ø  Message forwarding: The networks are sometimes divided in to a number of sub – networks which are then connected to other networks for facilitating wide – area communication. Here specialized hosts called routers or gateways are used for forwarding the packets from one host to another.

Characteristics of Network Layer

Encapsulation:

- One of the characteristics of the network layer is encapsulation. 

- Network layer ought to provide encapsulation facilities. 

- It is necessary that the devices must be identified with the addresses. 

- Not only the devices but the network layer PDUs must be assigned such addresses. 

- The layer 4 PDU is supplied to the layer 3 during the process of encapsulation. 

- For creating the layer 3 PDU, a layer 3 label or header is added to it. 

- In reference to the network layer, this PDU thus created is referred to as a packet. 

- On creation of a packet, the address of the receiving host is included in the header. 

- This address is commonly known as the destination address. 

- Apart from this address the address of the source or the sender host is also stored in the header. 

- This address is termed as the source address. 

- Once the encapsulation process is complete, the layer 3 sends this packet to the data link layer for preparing it to be transmitted over the communication media.

Routing: 

- The services provided by the network layer for directing the packets to the destination addresses define this characteristic. 

- It is not necessary that the destination and the source hosts must always be connected to the same network.

- In actual, the packet might have to go through a number of networks before reaching the destination. 

- During this journey the packet has to be guided to reach the proper address. - This is where the routers come in to action. 

- They help in selecting the paths for guiding the packets to the destination. 

- This is called routing. 

- During the course of routing of the packet, it may need to traverse a number of devices.

- We call the route taken by the packet to reach one intermediate device as “hop”. 

- The contents of the packet remain intact until the destination host has been reached.

De-capsulation: 

- On the arrival of the packet at the destination address, it is sent for processing at the third layer. 

- The destination address is examined by the host system for verifying whether the packet is meant for itself or not. 

- If the address is found to be correct, the decapsulation process is carried out at the network layer. 

- This layer passes the layer 4 PDU to the transport layer for appropriate servicing. 

Critical to do a smoke testing of the regular build - saves time and effort

For teams that have setup a smoke test of their regular builds, the benefits are such that they may not even understand about why such a post needs to be done; after all, it seems to be obvious that if you put a smoke test to do a quick check of the regular build (in our case, it was a daily build), there are multiple advantages. The most prominent advantage is that as soon as the build is available, the smoke test can be triggered to be run automatically, which in turn will take the build through a series of tests and determine whether there is a problem that needs to be resolved.
Sounds great, right ? After all, there are all advantages to having such a smoke testing of the regular build, but a number of teams do not use it, and at the same time, there are some additional effort that does need to be added in the calculation. Let me lay out the case which we used to have. Because of the size of our code and the amount of synchronizations that needed to be done with the source safe, we would have a daily build that would kick off in the night around 11 PM and typically get done around 7 AM. Now, the problem we used to have was that it was not possible to get anybody to be there to check whether, even if the build did get formed, whether the build would even launch and whether there were any major components or workflows that were broken.
When somebody from the testing team would typically get in around 9 AM, they would check the build and then provide their feedback. Our earnest hope used to be that there no problems revealed in this check. However, once in a while, the morning verification would reveal some problems that needed to be fixed, and it would mean that the build for that day would be late or would even have to be canceled, which had some impact on the defect find / fix rate.
The ideal solution was to have a smoke test run on the daily build. Now, the problem was that thought it sounded like an ideal solution, there were some incremental efforts that we had to calculate:
- Somebody had to write the smoke test cases and integrate that with the build system to provide an email output to several members of the team about the success or failure of the smoke test
- As and when we made some changes to any of the major UI or the workflows, we would need to update the smoke test to incorporate these changes. Sometimes these would get missed, and then you would find that the Smoke test stopped in the middle of some feature, and then it would take effort to do the diagnostic of what the problem was.
- The smoke test did yield some false positives as well. The team would then have to spend some time looking for the break in the build, and also examine whether this was a genuine catch, or whether the smoke test malfunctioned, and the problem could be ignored.
- The tools for running the smoke test could be expensive and the expenditure may need to be approved by somebody who does not understand as to why there is a need for such a software, so some amount of negotiation and discussion would be needed.
- Suppose the smoke test would start running at 7:30 AM and run for around 45 minutes, somebody from the team would need to be in place or looking at the report from the smoke testing at the completion time of the smoke test, and hence there would be a rotating chair where team members would be assigned this role for a specific period.

What is a virtual circuit? What are the advantages of virtual circuit?

The term VC or virtual circuit is synonymous with the term virtual channel or connection in the field of computer networks as well as in the telecommunications. 

- These are the connection oriented communication service.  

- The packet mode communication is the means through which this service is delivered. 

- After the establishment of a virtual circuit or connection between the two application processes or nodes, the stream of bytes or bit stream can be delivered between the two. 

- The higher level protocols are allowed by the virtual circuits in order to avoid the task of unnecessary dealing with the data division.

- This task may involve dividing data in to frames, packets or segments. 

- The virtual circuits bear a resemblance to the circuit switching mode under the fact that both of them are connection oriented.

- This means that both of them require correct order of delivery of the data. 

- Also, they both require signaling overhead during the establishment phase of the connections.

- The difference between the two is in the terms of the latency and bit rate. 

- It is constant in circuit switching and may vary in virtual circuits. 

This happens because of the following 3 major causes:

1. Varying length of the packet queues in the nodes.

2. Varying bit rate as generated by the application.

3. Varying load generated by the users who share the same resources on the network through statistical multiplexing. 

- A number of virtual circuit protocols are known for providing reliable services for communication but not all. 

- These services are provided by the means of data re-transmission because of the ARQ (automatic repeat request) and error detection. 

- Data-gram represents an alternate configuration for the virtual circuit. 

There are two types of virtual circuits namely:

Layer 4 virtual circuits: Data-link protocols such as TCP which are connection oriented and include segment numbering and thus reordering on the receiver’s side use this kind of virtual circuits. Thus out of order delivery is prevented. 

Layer 2/3 virtual circuits: The virtual circuit protocols of the data link  layer and the network layer are based up on the packet switching that is connection oriented. this implies that the delivery path of the data is always the same. 

Advantages of Virtual Circuits

There are several advantages of this kind of virtual connections:

1. They support the bandwidth reservation while the connection is being established.  This in turns increases the possibilities of QoS (quality of service). 

2. They produce less overhead. This is because of the fact that there is no individual packet routing and exclusion of the complete addressing info from the packet header. Each packet contains only a small VI or virtual channel identifier. The remaining routing info is provided to the network nodes during the establishment of the connection. 

3. Theoretically speaking, the nodes here have high capacity and are faster because their only task is to carry out routing. On the other hand, the network nodes in a connection-less network carry out routing for every packet individually. In switching, it requires only to look up the VCI in the table instead of analyzing the full address. Implementation of the switches is quite easy in the ASIC hardware but the complexity of the routing increases and demands software implementation. But as we know there is a huge market of the IP routers and layer 3 switching is supported by the advanced IP routers. 

Below mentioned are some protocols that provide VC facility:

- TCP or transmission control protocol

- SCTP or stream control transmission protocol

- X.25

- Frame relay

- ATM or asynchronous transfer mode

- MPLS or multi-protocol label switching

Introducing a code lockdown near the critical milestones ..

In a typical software development cycle, there are specific milestones near the end, with the expectation that the team would have stabilized the code and the product, and there would be few defects left near the end. However, there is a certain gentleman by the name of Mr. Murphy, who has a law called Murphy's Law (in our team, the definition of the law is simple - if something can go wrong, it will). So, as we approach near the last milestones, there are certain defects that do come up and need to be fixed. However, there are differences in the approach during the time when defect finding and fixing was ongoing, and the time when the team was close to the ending milestones.
The difference in approach is about the strictness in letting code changes go through. In the earlier parts of the cycle, the team would file defects, these would be verified by the developer and then the developer would make a fix for these defects and these would then flow to the tester. However, there were not too many restrictions on defect fixing and code changes, although defects that caused change in functionality or were risky were typically taken to a committee which approved the fixing of the defect, and at the same time, senior members of the team would be involved in code review to ensure that the code being checked in was as safe as could be determined during the process of code review.
However, as one reached closer to the ending stage milestones, there would need to be more restrictions used to minimise risk. At this stage, a problem in a defect fix could cause more problems to the product and even end up having some dependency issues on other parts of the code. The risk was too high of letting code changes go through without some kind of check. Towards this end, a dual check was introduced. The defects would all be passed to a defect review committee which would review a defect and give preliminary approval for some of the defects to be fixed, subject to a more rigorous review of the code. Once the committee gave an approval, there was a higher amount of inspection given to the code during the code review process, and once the approval was there, the code could be checked in the source safe. No code was allowed to be checked into the product area of the source safe (if developers were doing some other work, such as some advance work on a feature planned for the next release, then they could check in their changes to a different branch, but not to the main branch) unless there was approval (some teams have been known to actually put a check to ensure that no code was allowed into the source safe even by mistake, only when the administrator would give access would such a checkin be allowed).
Such a strategy may ensure that late breaking defects would not be easily fixed, but also would reduce the amount of risk in the end stages, and that is a pretty critical achievement.

What is Polling?

- Polling is often referred to as the polled operation.

- When the statuses of the external devices are actively sampled by a client program just like a synchronous activity is referred to as the polling. 

- The common use of the polling is in the input and output operations. 

- In rare cases, polling is also called as the software driven I/O or just simply as polled I/O. 

- As and when required, polling is also carried out with the busy waiting synonymous. 

- Polling is then referred to as the busy–wait polling. 

- In this case whenever it is required to carry out an input/ output operation, the system just checks the status of the device required for fulfilling this operation until it is idle. 

- When it becomes idle it is accessed by the I/O operation. 

- Such polling may also refer to a state in which the status of the device is checked again and again for accessing it if idle. 

- If the device is occupied, the system is forced to return to some other pending task. 

- In this case the CPU time is wasted less when compared to what happens in busy waiting. 

- However, this is not a better alternative to interrupt driven I/O polling. 

- In single purpose systems that are too simple, using busy-wait polling is perfectly fine if the system cannot take any action until the I/O device has been accessed. 

- But traditionally, the polling was thought to be a consequence of the operating systems and simple hardware that do not support multitasking. 

- The polling works intimately with the low level hardware usually. 

- For example, a parallel printer port can be polled for checking whether or not it is ready for printing another character. 

- This involves just the examination of a bit. 

- The bit to be examined represents the high or low voltage stage of the single wire in the cable of the printer during the time of reading. 

- The I/O instruction by which this byte is read is also responsible for transferring the voltage state directly to the eight flip flops or circuits. 

- These 8 flip flops together constitute one byte of a register of CPU. 

Polling also has a number of disadvantages. 

- One is that there is limited time for servicing the I/O devices. 

- Polling has to be done within this time period only. 

- But in some cases there are many devices to be checked which cause the polling time to exceed the given limit. 

- The host keeps on hitting the busy bit until the device becomes idle or clear. 

- When the device is idle, the state is written in to the command register and also in the data out register. 

- The command ready bit is set to 1. 

- The controller sets the busy bit once it knows that the command ready bit has been set.  

- After reading from the command register, the controller carries out the required I/O operation on the device. 

- On the other hand, if the read bit has been set to one, the controller loads the device data in to the data in register. 

- This data is further read by the host. 

- Once the whole action has been completed, the command ready bit is cleared by the controller. 

- The error bit is also cleared for showing that the operation has been completed successfully. 

- At the end the busy bit is also set.

- Polling can be seen in the terms of master slave scenario where the master sends inquiring about the working status slave devices i.e., whether they are clear or engaged. 

Checking for updates on social networking sites, and deciding whether to go ahead with them or not ..

Around 15 years back, the ease of getting user feedback on a software product was not easy, even for the large ones such as MS Office, Adobe Acrobat, or Photoshop. The principle way of getting this feedback was through the tech support route where users would call up tech support or deal with the support through email, primarily to provide some sort of complaint in a feature or look for some sort of health. Through this process, the support team could also get some sort of feedback on the product and the performance of the product with respect to the needs of the users. As for forums such as social networking, there was hardly anything that was available.
However, if you look at the current day situation, the forums where users can report problems (or more rarely, come out in praise of a product) are widespread. There are user forums, there are Facebook pages, there are email discussion groups, there are Twitter accounts that are used by users for reporting their feedback. When you consider a large product such as the ones in the first paragraph, the number of such forums and comments within them can be awfully large. Even for a team that puts in dedicated attention to looking, consolidating such feedback and respond to feedback that may not be so positive, it can be hard to catch up and respond to such feedback.
And therein lies the danger. When there is feedback and yet no reaction from somebody from the product team, it can seem odd, and lead to complaints that the organization and the product team do not care about user feedback, and so on, leading to something that is negative in terms of perception. Does this mean that you should put in a lot of effort on monitoring and responding to such kind of feedback ? Well, it sounds good, but monitoring and responding to feedback across different social networking forum can be pretty difficult and time consuming, and you might not have enough resources dedicated for this work (and resources with some amount of expertise in such new generation forums can be expensive, since it is not just monitoring, but actually feeding them into a system that lets the team figure out responses and strategies).
The idea situation would be where you have a broad user base that takes on most of the work of responding to such feedback. If you take Photoshop, complaints and criticism from users are many times responded to by other users, which also has a high ring of authenticity to the responses, and shows the commitment of members of the user base. In that sense, a committed user base is worth a large amount of effort and money.
However, there does need to be effort put in for building up such a committed user base. The team needs to be prompt in responding to issues that are gathering track (it would be very difficult, if not impossible, to respond to each and every issue) and show some quick responses. The team also needs to make the users feel that the product and support teams are responsible and geared towards the needs and concerns of the users (this may seem subjective, but it is necessary for this kind of feeling to be generated, as projecting such a feeling through actions inspires confidence in the team from the user community and every satisfied user can then become another committed member of the user community).
Other actions would be for the product to have its own specific Facebook page and Twitter account, maintained by somebody who has an appetite for the kind of enthusiasm and social skills that are required for social networking (if there are no tweets for many days or no Facebook updates, it tends to put off users and also seems to show the product and organization in a poor light). Further, members of the product team who are more well know can also have their own social profiles and send out updates of their own, and these also help.