Future of Software Development



The Future of Software Development



PREFACE


In the year 2000, nearly a quarter of all commercial projects in the U.S. were canceled, at an estimated cost of $67 billion. The failure of large projects and the significant cost overruns for many of those that are completed indicates that new ways of programming are needed.

An example of the cancellation of a large commercial software project is the rewrite of Qwest's customer billing system, canceled in October 2000. On the government side, the Bureau of Land Management's ALMERS software project was canceled around 1999. These are just two of many high-dollar projects that were terminated after more than $100 million had been spent on them.

THE PROBLEM
The complexity of large software applications has made new development difficult to complete. Maintenance of large applications is challenging. A Carnegie Mellon University study showed that programmers make 100 to 150 mistakes per 1,000 lines of code that they write.

PROPOSED SOLUTIONS
Current research is being done to try to overcome problems involved in creating and maintaining complicated programs. The approaches addressed here involve modeling very large applications. One researcher is attempting to develop a way to automatically generate program code from a model.

UNIFIED MODELING LANGUAGE
An approach to improve the creation of program code is the use of the Unified Modeling Language being developed by IBM. This modeling language is used by programmers to model an application based on the user's needs. After the model has been finalized, programmers can write code to reflect the model. This approach still requires the programmers to code the programs, but it helps programmers and users to understand and agree on the requirements and functionality of the proposed system.

Another idea is a proposal to create a model of the large application before programming is started, then use intelligent software tools to convert the model directly to program code.

MODELING EXISTING PROGRAMS
James Gosling, a research fellow at Sun Labs and the inventor of Java, is working on a project called Jackpot that will provide the ability to feed an existing program into a modeling tool to create a graphic representation of it.

TOOLS TO CONVERT A MODEL TO A PROGRAM
Intentional Software, a company run by Charles Simonyi, former researcher at the Xerox Palo Alto Research Center (PARC) during the 1970s, who later became chief architect at Microsoft, is trying to automate the code writing portion of the software development process to reduce bugs.

Simonyi's proposed solution is to create programming tools to assist writing bug-free programs and make the code look like the design. The idea is for a programmer to convert application requirements into a chart format from which powerful tools create the code. After the code has been created, the user community could modify the code without the help of a programmer. Programmers would become program designers. The detailed programming work would be accomplished by the software tools.

AUTONOMIC COMPUTING
Autonomic research is looking for ways to created "self-healing" software that fixes itself when a problem occurs. For example, when some poorly written programs are run several times, memory leaks can cause memory to be used up so that nothing can run. The solution is to reboot the computer. A goal of self-healing software would be to detect the memory problem and reboot the system automatically.

Microsoft's Windows XP already has some autonomic concepts in it. It stores models of its original configuration so that if a program becomes corrupted, it can be restored without having to reboot the computer.

EXTREME PROGRAMMING
This concept is designed to eliminate problems that programmers face when developing code and to shorten development cycles. The rules for extreme programming follow.

  • Shorten development cycles
    Break long development cycles into shorter time spans such as two or three weeks. This gives the programmer the satisfaction of meeting multiple short-term goals instead of having to wait more than a year or two to reach the final goal. Shorter cycles also allow clients to provide changes to the program design at the beginning of each cycle. The changes are then made part of the goal for the new cycle.


  • Do the simplest thing that could possibly work
    This rule says that if a program is so complicated that it would be difficult to modify later, it is too complex and should be broken down into two or more smaller programs.


  • Implement new features only when you need them
    Programmers sometimes add code for features that might be needed in the future. However, because this code may not be needed, because it requires additional time to write and test, and because it obfuscates the rest of the code, it should not be written until it is actually needed.


  • Programmers work in pairs
    By working in pairs, sharing one workstation, programmers can catch each other's mistakes, review each other's code, and exchange knowledge during the coding process.


  • Customer interaction
    Being able to get information from the customer is essential during code writing. A customer who can answer questions and prioritize work should be on site and available.


  • Sustainable work pace
    The schedule should be designed to permit programmers to work regular hours. Overtime should not be allowed unless it is absolutely necessary. "Death march" projects do not produce quality software.


JUST-IN-TIME PROGRAMMING
This concept allows a user of the software to make a change to the software model which triggers the regeneration of the code from the model with the new changes in place for immediate use.