OSD Development Process
October, 2006 Peter Wong, Orient Software
5. About Orient Software Development Corporation
1. Executive Summary
Change is the only constant in life.
Change defines the complex and challenging undertakings of software development. Even the ‘soft’ in software presents the misguided impression that software can be and should be easily changed. This is a reality that all project managers, team leaders, developers, clients and users must be aware of and learn to live with. This reality is especially more prevalent in offshore software development where the added challenges presented by geographic distances, cultural differences, language barriers, and domain knowledge deficits between clients and software developer makes communicating changes even harder, and more frequent. Without being accommodating change or controlling it successfully, offshore development projects will most likely run late and over budget.
Refactoring is one technique that can be used to accommodate and manage change in offshore development projects. Refactoring helps to maintain the quality of software in the face of changing requirements. It is a disciplined way of restructuring source code without changing the external behavior of the software. In short, it is about cleaning code, in a way which does not introduce bugs, but improves the changeability, maintainability, and understandability of source code.
Although Refactoring is a widely known discipline, it is not widely used. The impetus is due to the business pressures on project managers, CIOs and other high level technical managers. They believe that Refactoring wastes valuable time and resources, where in fact it actually is time-saving and cost-saving. Most developers understand the benefits of Refactoring, as they know that it makes their programming tasks much easier, but they don’t Refactor because they are not given the time and encouragement by their project managers, team leaders or even clients to Refactor.
High-level technical managers must account for Refactoring in their effort estimates. In fact, they must go further than that and encourage and demand that Refactoring be the technique that should be used by developers to continuously improve the quality of their work. No longer must the development management team view that the developer’s job is to just add ‘new features’ to the software. Using Refactoring, the software code will see many benefits, which will ultimately lead to shorter development cycles, lower costs and improved ROI in offshore development projects.
2. The Moving Target Problem
According to research by the Gartner IT consulting firm , the failure rate for offshore projects is about 50 percent. In another study, only 33 percent received a satisfaction rating. This generally poor performance manifests itself in projects being:
- Delivered late
- Over-budget
- Unsatisfied user’s requirements and expectations
- Software of low-quality
- Software difficult to maintain
Although poor results are not unique to outsource projects, they are prevalent because of the challenges that outsource projects presents. Geographic dislocation, cultural differences, language barriers, and domain knowledge deficits between clients and software developer are just some of the causes of problems which when not managed and controlled appropriately will lead to these project failures.
One of the primary causes of these failures is constantly changing requirements. Also known as the ‘moving target’ problem, changes in what is expected of the software while it is in development causes projects to run late and over time. If not managed and controlled in a disciplined way, and especially if under time pressures, developers and managers will adopt the management’s push to”just get the job done”. This inevitably leads to decay in the software quality and results in the software being difficult to maintain.
Why do requirements constantly change?. There are a number of factors that can cause changes in the requirements of software.
- Users don’t know what they really want: Users don’t know what they really want until they have the product in front of them and can pick out things that don’t work for them and what things that do work for them.
- Offshore development teams don’t know what the users want. What the user wants is sometimes not effectively communicated to the offshore development team. Many factors can be the cause of this.
- It could be because of language barriers and cultural differences that can lead to misunderstandings
- It could also be because of the means of communication restricting the message. Usually in the offshore development setting, most.
- Communication is restricted to emails, IM and phone conversations instead of the richer, and more interactive face-to-face communications.
- Also, because of time differences, there are sometimes delays in getting messages across and the lost in immediacy can loose some of the intentions of the messages.
- It could also be because the offshore development team has inferior domain knowledge than an internal development team.
- All these factors can lead to miscommunication and require subsequently more change requests to rectify them.
- Software is perceived as ‘soft’: Users and clients perceive software to be easily modifiable. They don’t give it a second thought to ask a software engineer to port an operating system to a new hardware platform, but would be more hesitant to ask a bridge engineer to relocate a bridge down the river.
- The regulatory and business environment changes: Changes in the regulatory and business environment can require changes to the features of software. A new tax law or changes in your business structure are examples that could affect your accounting software.
- Hardware changes: Changes to the hardware platform on which the software is executed will definitely invoke changes to your software.
- Staff turn over: When there is a change in people on the development team, this will affect the software in development as old staff will take with them some knowledge of how the system works and new staff will initially put their ‘dirty hands’ on the code.
- Good software will require change: A good software system will be in use for much longer than a failed system and it will inevitably evolve with time.
3. Refactoring to the Rescue
One effective solution gaining widespread recognition to effectively manage and control ever-changing requirements in offshore development projects is to use Refactoring in an Agile development process. Refactoring is a disciplined way of restructuring source code without changing the external behavior of the software and generally results in improved code quality.
Refactoring uses small steps in changing code so to minimize the introduction of bugs while restructuring the code. The changes can result in small changes, such as the renaming of a method, to larger changes, such as the separation of domain code from presentation code. Essentially, Refactoring seeks to clean code by removing duplicate code, breaking-up long methods and classes, isolating changes to one area, removing dependencies in code and even removing the necessity for large comments.
Refactoring aims to achieve the following benefits:
- To make code more maintainable: Most projects spend the longest amount of time and effort in the maintenance phase of the software lifecycle. This is especially true with hastily built projects which end up with many bugs and unsatisfied requirements. The challenge in making code easier and cheaper to maintain is a central issue for the life cost of an application. Refactoring allows developers to restructure code so that changes, additions and deletions can be made with ease.
- To reduce bugs in code: By making code more readable and maintainable, Refactoring helps to find bugs and eliminate bugs more readily.
- To improve the software design: Without Refactoring, the design of a software application will decay. As the code is changed in an ad-hoc fashion, the code loses its structure and it becomes harder to see the design from the code. As the design becomes less visible, further changes will destroy the design even more. Refactoring allows developers to combat software decay, by restructuring code to reflect a better design.
- To speed up the development process: Refactoring may seem as housekeeping work, adding more overhead to the main goal of adding new functionality to software. This is a shortsighted view. By making maintenance simpler and reducing bugs in the system, Refactoring reduces cost and effort in the maintenance phase. Since most project’s costs and time is spent in the maintenance phase, this results in achieving more savings in cost and time over the life of the project. In other words it actually improves the overall ROI as well as time to delivery of the software product. This point is arguably the most contentious among managers. Most managers don’t see the time savings in using Refactoring. However, a recent controlled experiment conducted by academic researchers support the claim that Refactoring saves time. They observed that regardless of the experience of developers, those who completed changes to a refactorized version did it in less time than those who completed changes on a non-refactorized version.
A particular recent experience we had where Refactoring was a critical factor in the success of a project was in the development of a tourism portal commissioned by a Vietnamese entrepreneur who is also a popular Vietnamese TV personality. Being the dynamic and enthusiastic client that he was, he almost daily had new ideas and requests which he would communicate with us at any time of the day or night. Knowing he wasn’t a typical client we have dealt with before, one who was not technically knowledgeable, we prepared our team early on to expect many change requests. Our team practiced, at every opportunity possible, Refactoring to ensure that the system maintained openness and flexibility. This helped to ensure that the project was delivered on time, with all the requests by the client fully satisfied.
4. Conclusion
Change is an inevitable part of life. This is especially true in the life of an offshore developer where geographic disparity is more pronounced and further impacts on the challenges of managing changing user requirements. Refactoring has been proven as a valuable tool in managing and controlling user requirements. It has also been shown to produce the higher quality software that offshore providers need to compete with now that lower operating costs are no longer the only determinant in the decision to engage their services. With Refactoring, offshore software companies can face head on the winds of change and their clients can rest assure they will get the right product, when they want it, at the price they want it.
5. About Orient Software Development Corporation
Orient Software Development Corporation (OSD) specializes in providing state-of-the-art software solutions and services which are cost-effective, of high-quality and exceed our customer expectations. Orient Software is a Vietnam-based company comprised of a workforce of talented, dedicated, and experienced software professionals managed by internationally experienced project managers. Orient Software provides leading-edge, yet practical solutions to its customers with the advantage they seek to succeed over their competition. Our customers are our partners, collaborating with us in the development of solutions that directly add value to their business to drive their ONGOING SUCCESS.
6. Contact Us
Contact:
Ms. Nhung Nguyen: Managing Director.
Headquarters:
Address: Orient Software Development Corporation, Suite 5.8, 5th Floor, E.Town Building, 364 Cong Hoa Street, Ward 13, Tan Binh District, Ho Chi Minh City, Vietnam
Phone: +84 28 3812 0101, Fax: +84 28 3810 5273, Mobile: 84 908282021, Email: [email protected]
References:
1. J. Rottman, “Successfully Outsourcing Embedded Software Development”, Computer, January 2006.
2. T. H. Ng, S. C. Cheung, W.K. Chan, Y.T. Yu, “Work experience versus Refactoring to Design Patterns: A Controlled Experiment”, SIGSOFT’ 06/FSE-14, November 2006.
3. M. Fowler, “Refactoring: Improving the Design of Existing Code”, Addison Wesley, 1999.
