Improvement of an Integrated Development Environment - Case Study Example

Computer Science Research Proposal The premise is that I work for a software company and I am proposing an improvement to an integrated development environment. Abstract Debugging is the most time-consuming process in software engineering. Coding errors are hard to detect, since having even one line wrong can produce disastrous results. Many programmers detect bugs by filling their code with output lines to see what the values of their variables are. This is a very inefficient method, and although tools exist to make the process faster, they are seldom used, perhaps because they are hard to use or because programmers don't feel the need to use them(GraphViz). Main Objectives My objectives are to cut the cost in time and money of debugging code, and to create a profitable software package for other programmers. Our company stands to gain by creating a smart and easy-to-use debugger. It will make the process of programming swifter and more efficient, leading to both profits by selling the debugger and savings by creating a more efficient software engineering process for ourselves. The main improvement of our debugger over other debuggers will be a visual component; complex data structures like graphs, tables, and trees will be displayed visually as the programmer conceptually sees them, not as lines of text. There are three possible directions to take concerning adding a visual debugger to an integrated development environment, or IDE, which is a program used to create programs. First of all, we could create our own IDE and implement the debugger along with it. This option would take longer to develop than the first, but would not have the difficulties of interfacing with other IDE's, since the debugger would be tailor-made for our own IDE. Also, we could stand to charge more for this product than for a plug-in(GraphViz). Secondly, we could create the debugger as a plug-in for an environment such as Visual Studio or Eclipse. This would take less time and be cheaper than other options, but may lead to difficulties in interfacing with a variety of IDE's, and may be unstable. Finally, we could link an existing IDE and an existing graph displayer but program the interface between the two. This would take the fastest among the three options but would not lead to much actual profit by sales. It would, however, improve the efficiency of our own programming practices. As for the schedule, option 1 could take many years; it would probably demand constant attention. Several years would be a reasonable period for option 2, and option 3 could be done in a matter of months. The duration of one development cycle within these schedules would vary depending on how many versions we release to the awaiting public, among other factors, but the ideal development cycle would be one version per year. Both Eclipse, which was open source starting on November 7, 2001, and GraphViz, which started in 2000, have maintained a nearly annual release schedule. Management of this Software Management of this project depends on how components of the project will be subdivided. Option 1 will need many more teams and a large staff, to cover the many aspects of an IDE. Option 2 could require one team for interfacing with IDE's, a large one for displaying graphs visually, and other smaller teams for the execution window and the variable window. Wages for programmers could run around $20,000 a year a person. Computer equipment and office space, which requires property taxes, will be needed. I conclude that, with the need for cutting the cost and time associated with debugging, this project is worth the costs, and option 2 is the optimal choice. Introduction An integrated development environment puts jointly the whole lot needed for programming into one application: a text editor, a compiler, a runtime environment, a debugger, and other tools. Some instances of these applications include Visual Studio, JBuilder, and Eclipse. Integrated development environments, or IDEs for small, need an operating system with windows, and make programming much additional user-friendly than programming on a command line such as DOS or UNIX(http://focus.ti.com/dsp/docs/dspsupporto.tspsectionId=3&tabId=454). Many improvements have been made to IDE's; they are constantly evolving and many, such as Eclipse, are open source, allowing programmers from around the world to make plug-ins or improvements to the original application. Working to create or improve IDE's is in the best interest of a software engineering company; not only because such software can be sold or bring in royalties, but because they can improve the efficiency of coding within the company; it is a product the company can use itself. One important feature of IDE's is a debugger. A debugger allows only a part of a program to be run; the user inserts breakpoints in the code, and when the debugger runs, it will execute all instructions in the code until it reaches the breakpoint, then stop. This allows programmers to see a snapshot of the state of the computer after running some portion of their code. Most debuggers in IDE's have several windows. One window tells the "story" of a program run: the choices it made, the subroutines it entered, and so on. Another says what the current state of the variables is. A variable is simply a piece of data. If, for example, the programmer inserted a breakpoint when the program had counted five of something and called its variable for counting 'x,' the variable window would show the value '5' under 'x.' One window would display the code, that is, what the programmer told the computer to do. This window is where breakpoints are inserted. Finally, the last window would show the output of the program: errors, messages, and whatever else the programmer told the program to display to the screen. However, most of the work in debugging is left strictly to the programmer. If a program is not doing what it was intended to do, one must insert countless instructions in the code just to display the value of variables or otherwise track down where the bug is coming from. If a program has to create large data structures, such as trees, graphs, or tables, it can be difficult to see what's going wrong. Debugging is thus one of the most time-consuming, and thus most expensive, stages of the software development process. Also, most of the output of a debugger, even in a windows application, is text-based. Data structures must be read line-by-line, not like a picture or a graph like how programmers would visualize it. However, even though they are not yet part of common IDE's, tools have been made to view complex data structures. A graph displaying utility, such as GraphViz, has the ability to take in a large data structure and create an visual representation of it, in a standard image format such as a gif or png file. It is a difficult problem, given any complex structure, to display it in an easy-to-read format. Only until recently have people begun to tackle it; graph displaying is a relatively new field. Accordingly, it is my proposal that this company tackle the problem of integrating a graph displaying utility into an IDE, thus making it even more user-friendly. Specifically, the IDE will be given a visual debugger; complex data structures as they exist in memory will be displayed to the screen exactly as the programmer would conceptually visualize them. There are many benefits the company could gain from a visual debugger. First, debugging is the most time-consuming part of programming. Any feature of an IDE that could make this process go quicker would be highly benefitial to the industry and any company working in it, including our own. Furthermore, the debugger could be patented and sold, bringing more opportunities for profit, but this is contingent on the amount of original work done. The more the company relies on existing open source applications, such as if we decide to create a plug-in accessory for an existing IDE rather than creating a whole new one, the less opportunity for profit can be made. However, for any benefit to be seen, visual debuggers must first be embraced. Many programmers are content with the tools they have, so I did some preliminary research into how the public would respond to such a feature. For this reason, I gave eighteen people a questionnaire about programming(http://focus.ti.com/dsp/docs/dspsupporto.tspsectionId=3&tabId=454). Of those eighteen, ten responded that they worked with debuggers. Of those ten, only one said their debugger had the ability to display graphs. Four said it did not have such an ability and five did not know whether it did or not. Furthermore, seven of the ten said they would use their debugger more often if it could. Also, twelve of the eighteen said they would rather see information portrayed in the form of pictures rather than words. This suggests that a visual debugger would indeed be more user-friendly than the kind that exist now. As a first step, more research on a wider scale must be made to truly judge whether a visual debugger would be well-received. These preliminary results suggest that it would. Most of this further research could be facilitated by setting up and advertising a website about the project. Forums and polls should be added to the website, as should news about the progress of the project. Software is released not once but in cycles, and requirements change based on the needs and desires of its users, so multiple prototypes and versions of the actual program should be released on the website as well. The next step would be to decide on a direction for the project. For that reason, the rest of this report will be devoted to exploring three very different directions the project could take. The cost, schedule, ease of development, stability, and opportunity for profit of the project vary with each choice. An entire IDE could be developped, with a built-in visual debugger; a visual debugger could be created as a plug-in to one or more existing IDE's; or a plug-in to an existing IDE could be created which uses an existing graph displaying utility, leaving only the interface between the two to be programmed. Option 1: Create a new IDE First of all, an entire IDE could be developped. A text editor, a runtime environment, a compiler, a debugger, all would have to be done independently. This would clearly be the most expensive option. Most IDE's are developped by very large companies like IBM or Microsoft. Furthermore, users would expect the same features and then some in a new IDE as in an existing IDE, since otherwise there is no reason to switch. For that reason, even more options than the visual debugger may be needed. Users may also expect new versions to be released as frequently as in existing IDE's, or else they may lose interest. Thus, a new version should be released every year in order to compete. To fulfill this schedule, a large staff would be required. A separate team for each component (text editor, compiler, debugger, etc) of the application would be made and a manager assigned to each. Professionals in visual programming would be required, and coordinating the efforts among the teams would have to be done by even higher levels of management. According to Cain, the average wages of Iowan computer science graduates is $41,250. Using this as the programmers' wages, labor would cost well over one million dollars with twenty-five programmers or more. There would barely be an end in sight for the entire project, because users think of new requirements every time a version is released. The project would be ongoing and require the attention of the company indefinitely. Thankfully, this effort would not be without its rewards. The entire project would be the intellectual property of the company, so it could be patented and sold for royalties. The program would likely be more stable than in the other options, since very little interfacing would have to be made with outside programs. The entire project would be white box that is, done with complete knowledge of how each component works (http://www.script-debugger.com/). However, for this option, profits would be quite unpredictable. It is a big risk devoting so many resources to this project, and an even bigger risk breaking into the IDE market. Competition is stiff, and many competitors are out there. According to Eclipse.org, many corporations, including IBM, Borland, and Red Hat, come together to produce Eclipse. Visual Studio is made by Microsoft. Competing with these giant corporations would be unfeasible. Even worse, many IDE's are open source and free for download, and most users would choose something well-tested and free over something new and not free. Option 2: Create a debugger for an existing IDE Secondly, the company could create a plug-in for an existing IDE. The only major hurdle in this option would be finding a way to display a graph for any given data structures in memory. The cost would not be nearly as high as in the first option and would require less management. At the start, one manager and a team of four or five programmers will probably be enough to meet an annual deadline for version releases. That would mean about $206,250 annually for labor. GraphViz is a similar project that employs ten people. Furthermore, graph displaying is a difficult and relatively new field, so it may not be as hard to break into this market as into the IDE market in general. The programming and/or graph displaying community may welcome a newcomer(http://www.script-debugger.com/). However, this option has a few minor drawbacks of its own. There would be less opportunity for profit as in option 1, since there would be less in this project that our company could call its own. Under the open source licenses of most IDE's for which the plug-in could be made, our company may not be able to claim the plug-in as its own property. However, the graph displayer alone, without being put into the debugger, would be our property. Also, adding the graph displayer to an existing IDE may make it unstable, depending on whether the IDE is open source. If we have access to the source code of the IDE, it would be easier to link in our debugger, knowing how the IDE itself works, but if the source code is closed, adding the debugger may be more difficult, resulting in instability. Option 3: Link an existing IDE and an existing graph displayer Finally, our company could take the easy route, programming a debugger as a plug-in to an exising IDE that uses an existing graph displayer to show the data. The biggest advantage of this option would be that it is relatively fast and easy. Management would be minimal; with time, one programmer could finish this project in a few months or less. Multiple cycles and versions would most likely not be necessary, and the project would not require the constant maintenance of the other projects. Using this option, we would most quickly reap the benefits of the end result as programmers who could use the visual debugger. However, as a profit-making company, taking this option would be unambitious. Practically nothing used could be sold, since it mostly uses the work and property of other companies and individuals. There would be some difficulty in getting it to work, related as before to whether or not the components used are open source or not. If we don't know how the IDE or graph displayer are programmed, we may end up with bugs we can't fix. The actual options of the debugger would also be limited by the IDE and graph displayer used. If the graph displayer is limited in its options, so too would our debugger be limited in its options, and we would have no way to improve it(http://www.script-debugger.com/). Recommendations In the end, option two is probably the best choice. It offers the challenge of graph displaying, something that could be marketed to other programmers. It is just ambitious enough for a company of our size; the first option is only feasible with large companies and the third is more of something that one programmer could do in his or her spare time. The final result would offer the surest profits of the other options. The first option could, with luck, offer greater profits but would be risky and very difficult, while the third option would offer virtually none. Focusing on graph displaying, however, is an attractive choice since it is relatively new. Conclusion In conclusion, debugging is the most time-consuming, and thus most expensive part of programming. If our company could aid programmers, both inside and outside the company, by allowing data to be shown with pictures instead of words, it would be a big step in solving the debugging problem. Implementing a visual debugger as a plug-in to an existing integrated development environment would be the best choice for a company of our size because making a whole new IDE, while lucrative and giving us the most control, would be too ambitious and implementing a debugger using an existing graph displaying utility, while being relatively easy and likely to be finished quickly, would not be ambitious enough(Xavier Spriet, 2006). Glossary Black box: Testing or using an existing program without knowledge of its internal workings; a closed source graphics utility would be black box and thus harder to embed into a debugger with confidence that it will work as expected. Bug: A mistake in a programmer's code. While the code may compile into an actual program, if it does not do what the programmer intended, it has bugs. Code: See source code. Compiler: A program which takes instructions written by a programmer and creates a program to carry out those instructions. Debugging: The process of removing bugs. It is the most difficult, expensive, and time-consuming part of programming. Integrated Development Environment: An application in a Windows or Windows-like environment that puts together all the tools needed to program: a text editor, a debugger, a compiler, a run-time environment, and so on. Open Source: Having a program's source code released to the general public; the code is still the intellectual property of its programmer, so other programmers who use the code have little or no property claims to their modifications of it. Programming: The act of creating programs. The process includes designing code, writing it, compiling it, testing the program that results, and debugging it. Prototypes: Initial versions of a program; they usually do not have all requirements met. Requirements: The set of features that a program must have in order to do what it is intended to do. Debugging ends when all requirements are met. Requirements are determined by users and customers of the programs as well as the programmers. Source code: The actual text that a programmer writes that a compiler uses to create a program. Subroutine: A set of tasks performed by a program. Tasks that one particular program is required to do repeatedly are usually set apart into their own subroutine. White box: Testing or using an existing program with knowledge of its internal workings; an open source graphics utility would be white box and thus easy to embed into a debugger with confidence that it will work as expected. Work Cited "ATT Labs-Research: GraphViz." 27 Apr. 2004 http://www.research.att.com/sw/tools/graphviz/. http://focus.ti.com/dsp/docs/dspsupporto.tspsectionId=3&tabId=454 http://www.script-debugger.com/ "Using Wing IDE has allowed us to improve the quality and reliability of the Python components of our application." -- Xavier Spriet, Netmon Inc, Jul 2006 Read More