- Software's Difficult Past
- What Makes Software Development So Difficult?
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
What Makes Software Development So Difficult?
Fewer computer users than ever before understand or even care about software development and its accompanying infrastructure. But software development continues to be very difficult, and mostly for the same reasons.
The Year 2000 and Similar Problems
Software has always been difficult to modify. Witness the billions of dollars spent by corporations worldwide to upgrade or replace approximately 36 million applications so they would function correctly in the year 2000 (Y2K) and beyond. Those unfamiliar with software development struggled to understand why something as simple as the representation of the year, a four-digit number comprehend by most kindergarten children, could wreak such havoc on software. Given software's difficulty in handling the Y2K issue, it's even more amazing that new programming languages such as Java could help accomplish such feats as bringing color images back from a small toy-like rover on Mars, and allow them to be displayed on our PCs at home a few minutes later.
Think the Y2K problem was a one-time occurrence in the history of software? Consider other, similar software problems:
Around 2015, the phone system is projected to run out of three-digit area codes, requiring changes to approximately 25 million applications.
In 1999, European countries switched over to a new universal currency, the Euro, for non-cash transactions. By mid-2002, the use of the Euro will be expanded to include cash transactions. These changes will affect approximately 10 million applications.
Around 2075, U.S. social security numbers, based on a nine-digit number, are expected to run out. Approximately 15 million applications that use social security numbers would be affected.
Structuring Development Organizations for Success
There are certainly more wrong ways than correct ways to structure a software development organization. No single organizational structure will meet every company's needs. Centralized development organizations are often too big to be responsive to departmental concerns. Decentralized organizations may not have enough staff to provide needed specialty skills. Nevertheless, certain organizational concepts apply no matter how you structure your developers. For instance, integrated software development teams, in which software architects, developers, testers, and other specialists are teamed together, almost always have fewer barriers to success than more traditional "silo" organizations. In the latter, software architects, developers, and testers are divided into separate teams and hand over the project from one step of its lifecycle to another. There are several problems with this type of organization:
It's not conducive to iterative development processes.
Since no group has ownership in the others' products, there is a natural tendency to blame problems on the work of another group.
Scheduling and Budgeting
While entire books have been devoted to software development scheduling and budgeting, it remains rare to find a software development project completed under budget and on schedule. One reason is that development managers often set software schedules and budgets early in a project's lifecycle, with little or no buy-in from the developers. Another reason is that many software development projects begin with pre-set budget or schedule limitations and then try to back into the eventual end product. Our best single piece of advice is to avoid using historical "magic numbers" from other projects when developing your budget or schedule. Accurate software development scheduling and budgeting requires that you understand the project, and know the developers, development environments, and other factors that will affect your schedule and budget.
Selecting Language and Development Tools
Language choice continues to have a major impact on software development projects, starting with the software architecture. For a given project, the software architecture will look quite different if FORTRAN is chosen as the development language than if the Java is chosen. Once a language is chosen, you also need to select one or more development tools. Many development tools start by having you design the user interface and thus focus on that task. Mapping the user interface to the back-end database and adding business logic is left as an exercise for the developer. Other tools start with the database design, and use this to derive the user interface and structure the business logic. In both cases, the developer is forced to trade off one design for the other. A better approach, although supported by fewer development tools, is to start by defining your business logic. Once the business logic of an application is designed, it's much easier to derive an appropriate user interface, along with the required back-end database structure.
Selecting the Operating System and Hardware Platform
In the future, platform-independent languages such as Java might make operating system (OS) and hardware issues irrelevant. Today, however, the OS and hardware platform continue to have an impact on software development. You need to consider a multitude of general requirements for hardware environments, including developer desktops, servers, and production hardware—as well as hardware architecture issues such as SMP versus MPP, and their impact on software architecture.
Accomplishing a Production Rollout
One of the most overlooked reasons for the failure of software projects is the difficulty associated with a successful production rollout. From bringing online a new corporate financial system to upgrading a simple software application, successful production rollout doesn't happen without careful planning and execution. Some of the best-designed and -developed software applications never see production use because they didn't take into account some important factor of the production environment. (Chapter 13 of Software Development: Building Reliable Systems [Prentice Hall PTR,, 1999, ISBN 0-13-081246-3] presents our proposed solution to the production rollout problem: the Web-Centric Production Acceptance process.) As with many software development issues, planning for production operations needs to begin early in the software lifecycle as the software architecture is being defined. This is one of the most common problems in the industry today, which we'll address in a future article.