Browse Prior Art Database

A system to track developer’s thought thread in IDE Disclosure Number: IPCOM000198638D
Publication Date: 2010-Aug-11
Document File: 8 page(s) / 119K

Publishing Venue

The Prior Art Database


Disclosed is a system(generally integrated into IDE) for tracking developer's thought thread by tracking the actions developer did during implementing a feature or fixing a defect.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 34% of the total text.

Page 1 of 8

A system to track developer's thought thread in IDE



     : Integrated development environment , a software development system , such as RAD (Rational Application Developer ), Eclipse, MS Visual Studio, etc.

1 What's the problem

IT industry already was there many years, we could notice that:
1: Legacy IT asset become more and more, and we must spend a very high cost to maintain it.
2: The number of software growth with a high speed. So, the system what we had to maintain growth quickly.
3: The code of software product becomes bigger and bigger, there were many tools to reduce the maintain cost, bit it was still high.
4: The developers transfer between projects/products/departments/companies frequently, it's very common to maintain other developer's code.

Let's look into the situation of developer:

As a developer, fixing defects of previous release / transferred project are a common work. Typically, the one who fixes defects is not the one who developed it. Hence, it is hard for people who are fixing defects to fully understand the whole product in a short time since there are some many projects, so many codes there. There are some pains for non-authors to fix defects.

1.1 We have to spend more time to find the reason.

Sometimes, we are not sure whether a line is wrong or not, whether fixing the line will incur more defects, etc. At this time, we often wish that we know how this feature was implemented and what the author thought when implementing it, e.g. what source files he touched. Unfortunately, there is no way to know it now via current IDE.


Page 2 of 8

1.2 It is hard to recall previous action history due to the limit our current IDE.

Sometimes, when we are locating an issue, we are interrupted and need to read other source files at the same time. After we read those source files, we want to resume fixing the defect and want to recall our thought with source files we opened previously. However with current IDE, it is hard to recall the source files we opened previously.

1.3 Here are two simple daily work scenarios of us

Scenario 1:
Ming and Bob are in a same development team, and both of them are working for Lotus Connections. But they are in different countries. Ming is in China, and Bob is in America and on vacation. Today Ming receive a critical defect


                                                        "fix user can not login issues". When he open the changed files history, he find Bob spend one week to fix this defect, but have no idea why he fix it like that. Ming is not familiar with it, and he even can not find the root reason. So, he may has to spend one more week to debug and analyze the defect again just like what Bob did if he can not what Bob did. He also will make the change very carefully, because he was worried to cause the regression defect by his code change.

Scenario 2:
Jack is working on a hard reproduce but critical defect. After spend lots of time to prepare the environment, and debug lots of code, finally, he find the issue maybe in class A.

java, bu...