When is a defect not a defect and should be classified as a feature ?

This is an interesting question that causes a large amount of debate in many teams during their development process. A defect is something that needs to be corrected (in terms of the discussion in software teams) - and this is without getting into the exact semantics of the definition of a defect. So, in the regular process, a tester finds a problem that needs to be corrected and is assigned to a member of the development team to fix. The development team member analyses the defect, finds the required change, and then makes the necessary fix, the fix is rolled into the product and can then be tested by the tester (the same one or somebody else) and if it is fixed, the defect is marked as verified and can be closed.
This works most of the time, but there are cases when the process does not work like this. For example, there are times when the defect that is marked in the system, when analysed, is found to have a big change. It could be that the fix for the defect causes a change in a code section or file that is used in a number of areas of the application. When this happens, it is not so easy to make a change, since there can be a large impact. The impact analysis of such a change needs to be more wide-spread, looking at the change that needs to be done in the different areas, the change needs to be thoroughly reviewed, and then once the change is made, a thorough testing needs to happen. However, this is not the case that I am talking about, where the defect is still a defect and not a feature.
The feature change is a different kind of defect. This is when a defect is logged which talks about some change in the workflow. It could be possible that when a defect is logged, the defect was logged on the basis of an interpretation of the tester, or the defect is actually tracking a specific point of the product where the feature definition was missing or flawed. Consider a case where a team has defined a new feature, where all the workflows that were written as a part of the product development were done, and then it was discovered during testing that the specific workflow of one area was not done as it should have been.
So what to do ? Well, whenever such a defect is written, it should be categorized as a feature rather than a defect. A defect means that the focus is more on the fixing of the defect, while if you are looking at the problem from a feature perspective, there will be more attention paid. The product manager, the designer, the feature team which was looking at the feature, all of them should be brought in, and they need to look at what the nature of the change should be, whether this impacts more than just the workflows before and after, and so on. It is also possible that if this is at a late enough stage, this group makes a decision that the feature will be left as it is, or the team recommends the change which is then made. Doing it as a feature will also ensure that other teams that need to look at feature changes such as documentation and localization will be informed as a matter of process. In the end, the treatment of such a change may be finally be done through the defect process, but this is done only after the change has had a thorough look at it.

Potential quality problems when using Open Source components in your software product - Reduced level of control

Most software applications use components or services from teams that are external to them - these could be teams within the organization, or these could be from outside the organization. Many applications even use components that are built by Open source processes. These components can be very useful, but one needs to be mindful of the impact of using external components, especially if you are in the role of a project manager or a program manager. If a critical component is late or is of bad quality, it have a critical impact on the schedule of your project.
I remember a case where we had a component that was important, and we had just taken delivery of a new version of the component (it was available on the web page of the Open source project and the notes mentioned that this fixed a defect that was critical for us). This was incorporated in a development version of the product, which was sent out to beta testers after a quick application of some test cases. Unfortunately, in this case, Murphy's Law hit us bad. The quality of the external component was bad, it destroyed some of the test data that customers were using. Now, although we would warn the customers that they should not use their live data in Beta testing, the Beta customers had a certain expectation in terms of the quality of Beta software that they were using, and the release was less than that. We got chewed out by senior management that one time, although there was little that we could do.
This gets very tricky when you use Open Source software, since there is a reduced level of control in using such components. However, in most cases, you will be forced to use atleast some amount of open source software. Many components are available as Open Source, which are otherwise available for very expensive sums. Software companies do the trade-off between the cost of a controlled component from outside and the problems that may happen when you use an Open Source component, and invariably, better use can be made of the money, and you will end up using the Open Source software. This is even more so when the same component is being used by other groups within the company, as well as by other product in the same space.
One compromise that can be reached is about deciding which version of the Open Source component to be used, and deciding the amount of testing that needs to be done before and after integration of the component.   So, depending on the phrase of the project, if there is no real dependency such as Beta testing or other such delivery, you could take the latest version of the Open Source software and test the hell out of it, and then decide whether to proceed with the component. However, if you are still in a state where you have some dependencies, then it would be wiser to take an earlier version of the component, which has been well tested and is good for use. If there is a bug fix that is there in the latest version of the software, then you would need to make a decision about the software to use.
Overall, the stand that you need to take is no easy call - there are a lot of benefits of using an Open source component, but you need to review the attendant benefits and problems, and then take a call.

What is a virtual memory?

- Virtual Memory is a memory management technique that is a compulsory requirement for the multi-tasking kernels. 

- With this technique, the architecture of a computer can be virtualized to different types of computer data storage such as disk drive storage and RAM i.e., the random access memory. 

- With this, programmers do not have to worry about designing applications that will suit this kind of storage. 

- The programs can be designed keeping in consideration only one kind of memory i.e., the virtual memory. 

- This memory behaves just like the usual memory but more than that. 

- It offers a direct as well as contiguous memory space for various operations. - Some of us might think that the programming the software might get difficult with the virtual memory. But this is not so.

- Instead the task becomes easy because the fragmentation of the main physical memory is hidden. 

- For achieving this, the burden of the management of the memory hierarchy is delegated to the kernel.

- This has another added advantage which is that the need for handling of overlays in an explicit way via program is eliminated.

- The need for the relocation of a program code or accessing the memory is obviated via relative addressing. 

- This lets the process to be executed in its own dedicated space. 

- The concept of the virtual memory in a more generalized form is called the memory virtualization.

- The modern computer architecture cannot do without the virtual memory. 

- The only requirement for implementing the virtual memory is the hardware support that is provided through the memory management unit that is in-built in CPU. 

- For increasing the performance of these virtual memory implementations hardware support can be employed by the virtual machines and emulators. 

- Computer systems with old operating systems such as DOS in mainframes  do not possess any functionality of the virtual memory. 

- The first computer that featured the virtual memory was the Apple Lisa that was designed in the year of 1980. 

- It appears that with the use of virtual memory as if every program has a sole access to it. 

- However, there were some older operating systems that had single address space Oss. 

- These operating systems used to process tasks in a single space. 

- This space is consisted of the virtual memory. 

- Very consistent response times are a requirement of the special purpose computer systems such as the embedded systems. 

- These systems do not prefer to use the virtual memory as it may decrease the determinism. 

- The unpredictable traps producing unwanted jitter while carrying out the I/O operations might be triggered by the virtual memory systems. 

- This happens because the cost of the embedded hardware is kept low. 

- The operations are included in the software rather than including them in the hardware. 

- This technique is termed as the bit banging. 

- The older programs needed to have logic for the management of both primary and secondary memory. 

- One such logic was that of the overlaying. 

- Therefore, virtual memory was introduced as a method for extending the primary memory and make this extension easy for the programmers.  

- In order to allow multi–tasking and multi–programming, the memory in the early systems was divided between many programs. 

Implementation of the virtual memory saw many problems. One among those problems was of the dynamic address translation that was difficult to be implemented and  quite expensive also. 

Designing software so that features can be stopped at a later point of time ..

Not sure whether the title of the post made sense, so am going to add more details right here. Let us take the case of Lisa, the user of the software. The software does greeting cards and allows users to take their own photos and add texts and the like. Now, some years back, the software had a facility that allowed users to take their final creations and save them to Yahoo Photos (which existed many years back, but does not exist now, especially after Yahoo had bought Flickr). In later versions of the software, the makers of the software would have removed this link to Yahoo Photos and modified the usage to point to some other site where photos could be hosted under a free account.
However, like most other users, Lisa does not upgrade her software application every time a new version of the application is created. So, even though the software in later versions is upgraded, every time Lisa uses the features in her software which connects to Yahoo Photos, some problems may occur. It could be that the error is something which makes sense, or it could be an error that makes no sense to Lisa, or it could be that the API call failing is something that is not handled well within the software and could even cause the software to crash whenever Lisa tries uploading photos to Yahoo Photos, which would not be a very good experience. In fact, in most of these cases, the experience that Lisa faces is not something that is a good user experience, and can cause dissonance and dis-satisfaction at the hands of Lisa.
For makers of commercial software, such a situation is very harmful, and yet you will find a number of software makers who are not ready to handle such a situation. And when you are trying to get your customers to upgrade their software, such problems are going to make it more unlikely that customers would appreciate the experience and want to upgrade. So, what do you do in such a case ?
Well, it is pretty important that the design of the application is done in such a way that features can be turned off later. So, the way to do this is to by making each such dependent feature call into a specific web site and ask for a specific parameter. If the parameter is a go, then the feature will launch and the user will get that specific feature. At the same time, if the parameter is a no-go, there would need to be some error handling that will inform the user about the problem, and also alert them about a web page where they would need to go for more instructions on what to do, and they can also be provided an explanation. Such a technique ensures that users do not feel that they are running into errors that cannot be handled. The beauty of this type of handling is that even if this problems comes in a product version that was released many years back, you can still go ahead and ensure that the users do not face major errors; and in fact, if the functionality is important to your users, you can inform them about the problem and that it has been handled in the latest version and show them an upgrade path.

Explain the concepts of threads and processes in operating system?

Threads and processes are an important part of the operating systems that have features of multi–tasking and parallel programming. These come under the sole concept of ‘scheduling’. Let us try to understand these concepts with the help of an analogy.

- Consider the process to be a house and threads are its occupants. 

- Then, process is like a container having many attributes. 

- These attributes can be compared to that of a house such as number of rooms, floor space and so on. 

- Despite having so many attributes, this house is a passive thing which means it can’t perform anything on its own. 

- The active elements in this situation are the occupants of the home i.e., the threads. 

- The various attributes of the house are actually used by them. 

- Since you too live in a house you must have got an idea how it actually works and behaves. 

- You do whatever you like in the house if only you are there. 

- What if another person starts living with you? You just can’t do anything you want to do. 

- You cannot use the washroom without making sure that the other person is not there. 

- This can be related to multi – threading. 

- Just as a part of estate is occupied by the house, an amount of memory is occupied by the process. 

- Just as the occupants are allowed to freely access anything in the house, similarly the occupied memory is utilized by the threads that are a part of that process i.e., the access to memory is common. 

- If one process allocates some memory, it can be accessed by all other threads also. 

- If such a thing is happening, it has to be made sure that from all the threads, the access to the memory is synchronized. 

- If it cannot be synchronized, then it becomes clear that the memory has been allocated specifically to a thread. 

- But in actual, things are a lot more complicated because at some point of time everything has to be shared. 

- If one thread wants to use some resource that is already under use by some other thread, than that thread has to follow the concept of mutual exclusion. 

- An object known as the mutex is used by the thread for achieving exclusive access to that resource. 

- Mutex can be compared to a door lock. 

- Once a thread locks this, no other thread can use that resource until the mutex is again unlocked by that thread. 

- Mutex is one resource that a thread uses. 

- Now, suppose there are many threads waiting to use the resource when mutex is unlocked, the question that arises now is that who will be next one to use the resource. 

- This problem can be solved by either deciding on the basis of length of wait or on basis of priority. 

- Suppose there is a location that can be accessed by more than one threads simultaneously.

- You want to have only a limited number of threads using that memory location at any given point of time. 

- This problem cannot be solved by mutex but with another resource called semaphore. 

- Semaphore with a count of 1 is the resource that can only be used by one thread at a time. 

- In semaphore of greater count more threads can access it simultaneously.  

- It just depends up on how you characterize or set the lock.

Ensuring that there are clear agreements over deliveries from third parties

In today's world of software development, most large products use input components from a variety of sources. So, if you are building a new version of a video editing application, it tends to incorporate a large number of external components - some of these dealing with the ability of read views of different formats and codecs, then there will be the components dealing with burning what you created to a disc for which there are additional components, and so on. In all such cases, it always makes sense to use components that have a specialized function rather than try to build it yourself. In the current case, see how it difficult it would have been if you team was trying to write code to read the different video formats in existence today. You would have mostly given up trying to do such a thing. Even otherwise, there are other components that are used - if you are working for a company that has multiple applications, the company would ensure that common components are built at one place and included in the various application (this is the most efficient way of building such components); for example, you would be using a Help system, your application would be using Installers for installing the application onto the machine, you would have having a licensing system, you might be having a common system for generating the UI of the application, and so on.
Now, this sounds like  the most efficient way of building such an application. However, for somebody who has been there and done that, there are many slips between getting a robust system in place that integrates all these components in your schedule. For example, one of the biggest problems that we used to run into was the quality level of these components. We had a contract with one of our component makers who would supply us a component (and they used to supply the same component to our rivals and other applications in the video space). From time to time, we would run into problems where these components would not be delivered in time, or where we would have to reject the quality level of the component, because we found a critical bug.
Why were all these problems happening ? I am talking about a situation which used to happen a few years back, and it was extremely frustrating. However, it turned out that we had been working with them for many years, and we had never really tried to set some kind of process for these deliveries of the component and hence all the problems. So, we started out by working the timelines for when we need these components, and then did more analysis while working with the development and testing teams about the level of testing that we expected from the vendor end. Now, all this was being done from our end, and we had only aired some level of frustration with the vendor, but never really got in a problem solving discussion.
We set up a series of meetings with the vendor, talking them through what the current system was, pointed out the problems it was causing for us (and for them as well, since when we rejected a version of the component, it would have meant more effort from their end as well). We talked them through some of the solutions that we were looking at, we got our development and testing teams to have discussions with their respective teams on a regular basis. Now, this was not a magic bullet; they did not do everything that we had asked for, and in some cases, it meant that we had to pay around 10% more because of the extra effort on their side. However, in the end, we had a more strict agreement for the delivery of the component along with a quality level, and this allowed up stability in a part of our schedule, which was well worth it. 

What is Paging? Why it is used?

- Paging is a very important concept for the computer operating systems required for managing the memory. 

- It is essentially a memory management scheme which is used for storing as well as retrieving data from the secondary memory devices.

- Under this scheme, the data is retrieved from the secondary storage devices and handed over to the operating systems. 

- The data is in the form of blocks all having the same size. 

- These data blocks are called as the pages. 

- In paging, for a process the physical address space can be kept as non–contiguous itself. 

- Paging is a very important concept for implementing the virtual memory in the operating systems designed for contemporary and general use. 

- This allows the disk storage to be used for the data that is not able to fit in to the RAM. 

- The main functions of the paging technique are carried out when a program attempts to access the pages that have no mapping to the physical RAM. 

- This situation is commonly known as the page fault. 

- In this situation, the OS comes to take control of the error. 

- This is done in a way that is invisible to the application. 

The operating system carries out the following tasks in paging:

Ø  Locates the data address in an auxiliary storage.

Ø Obtains a vacant page frame in the physical memory to be used for storing the data.

Ø  Loads the data requested by the application in to the page frame obtained in the previous step.

Ø  Make updates to the page table for showing the new data.

Ø Gives back the execution control to the program.This maintains a transparency. it again tries to execute the instruction because of which the fault occurred.

- If space is not available on RAM for storing all the requested data, then another page from RAM cannot be removed. 

- If all of the page frames are filled up, then a page frame can be obtained from the table which contains data that will be shortly emptied. 

- A page frame is said to become dirty if it is modified since its last read operation in to the RAM. 

- In such a case it has to be written back in to its original location in the drive before it is freed. 

- If this is not done, a fault will occur which will require obtaining an empty frame and reading the contents from drive in to this page. 

- The paging systems must be efficient so as to determine which frames are to be emptied. 

- Presently many page replacement algorithms have been designed for accomplishing this task. 

- Some of the mostly used for replacement are:

Ø  LRU or least recently used

Ø  FIFO or first in first out

Ø  LFU or least frequently used.

- To further increase responsiveness, paging systems may employ various strategies to predict which pages will be needed soon. 

- Such systems will attempt to load pages into main memory preemptively, before a program references them. 

- When demand paging is used, paging takes place only when some data request and not prior to it. 

- In a demand pager, execution of a program begins with none of the pages loaded in to the RAM.