Plagerized from www.infostrat.com

The Challenges of Custom Application Development

Since one size does not fit all for line of business solutions, the traditional approach is to develop custom, one-of-a-kind solutions. The custom approach creates a unique opportunity to align your system with your business, guaranteeing that no organization will run itself quite like yours. Despite these benefits, custom application development carries significant risks and pain.

Why is Software Development So Expensive?

The high cost of custom software development is primarily due to three factors: effectiveness of requirements gathering, scope creep, and the development platform.

The Requirements Challenge

The most fundamental challenge of custom development is defining requirements. The process requires discipline, time, and the ability to make the right tradeoffs of cost, time, and functionality.

Requirements describe how a system is intended to operate, specifying how users will interact with the system and defining many of the aspects of the solution. A custom application is only as good as the requirements that define it.

While people generally understand the elements of a house, such as a roof, walls, and a floor, the devil is in the details. Most homebuyers would not pretend to understand structural engineering, electrical codes, plumbing, drainage, and ergonomic standards, so architects and builders spend significant effort developing detailed plans and designs.

With custom software, the problem is even more acute than in building a house. You would expect a house to be built from standard materials such as wood or brick, but users can easily ask for software requirements that are not practical or possible. House construction is common knowledge, but software engineering is not. It is a daunting challenge to present an end user with a blank sheet of paper and ask for a wish list of the features in a new system.

Many are tempted to answer quickly or avoid the question so they can focus on their daily responsibilities. Most end users do not have the time, experience, or motivation to supply well thought out functional requirements. When converting a manual process to an automated system, an organization runs the risk of “paving the cow paths,” or creating an automated system with all the inherent inefficiency of its manual predecessor.

Scope Creep

Another problem dooming many custom development projects is scope creep, when new requirements or changes are introduced after the original requirements have been approved.

Incomplete requirements may lead to mid-stream changes in a development project, boosting the cost and extending the time required to complete the system. For example, if you started building a one-story home and, halfway through construction, decided you really want a two story home, your decision would carry additional cost and risk.

Business rule changes, some caused by external factors such as regulatory requirements or competitive threats, may also precipitate change orders. Regulatory compliance can create scope creep, such as the Sarbanes-Oxley corporate requirements, or Federal records management requirements or Health Insurance Portability and Accountability Act (HIPAA).

The best requirements are based on an organization’s vision, anticipating the direction of future changes and allowing for dynamic business rules. For instance, instead of “hard coding” reference fields, developers can build lookup tables that contain reference information that users can change as necessary to prevent recoding an application. In most cases, building this flexibility into a custom system initially adds significant cost.

Development Tools

The choice of development platform determines the effort required for development. Some programming languages are more efficient than others at automating business requirements. In traditional custom development, more than half of development time is dedicated to solving common issues such as generic way to display data, data binding, security, audit, etc. In many cases, developers have to reinvent the wheel each time, or, at best, reuse some previously developed code blocks.