The survey of needs
This is not the most up to date version, but I’ve started writing in my latex file, so I don’t take the time to keep my .txt files up to date. Sorry.
This section will discuss the result from the survey about developers needs in an editor. After the survey had been up for 12 hours, nearly 40 different developers had sent in their feedback, which is nearly all of the developers that had received the e-survey by e-mail. Other communication of the survey was done through word of mouth, whiteboard in lectures, and info screen spread around Department of Informatics. I will start of presenting the survey in its full, then discuss the ambiguity some of the questions rose. At the end a discussion of what this survey teaches will be presented.
There where a total of 5 mandatory questions, and three text boxes to add more information. The first question where not really necessary for this survey, but helps to show the representation of the developers that answered this survey. As predicted mos of the feedback was from developers rating them self as something in the middle and up of just started and experienced programmer.
Since this survey where focused on what editor features developers uses, there was a certain need to find out what tool they use when developing, and if they use the features I predicted was necessary for an editor. As it not only important to find out what features they use, it can be relevant to see how much they use that certain feature, so there where also table asking for how much they used each of the features. Ranging from “not used”, “uses” to “uses all the time”. Between what kind of features a developer uses and how much they use it, I had a question asking what kind of features they felt was necessary to make a good IDE/text-editor. The text-boxes in this survey was there to let the participant elaborate to either the features they thought was needed for a good editor, other features the often use, or just wanted to add some extra thoughts about this survey or IDE/text-editor generally.
After I had sent out the survey some of the recipients came to me to discuss some of the questions and answers. It quickly arose that people had not read the transfiguration in the description. Which in turn led to users answering the questions with different features in mind. Especially ‘refactoring’ and ‘source tree’ where to features that the users had misunderstood or thought was directed to other features. The obvious reason behind this misunderstanding is that the survey participant did not read the description before they did the survey and did then not get the explanation about the different terms used in the survey. The not so obvious reason is that the two terms ‘refactoring’ and ‘source tree’ are also used to describe other features.
When we talk about refactoring in generally, developers often think about code refactoring. Best describe by Martin Fowler
”Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.” (www.refactroing.com)
So the case in this survey may have been that participants have been thinking about code refactoring, which is something no tools naitvely supports. As this often is a difficult task, even for humans. Which would often make it even more difficult to make a feature that would do it automatically. The name refactoring in this case comes from Eclipse, and their use of refactor or refactoring.
the ‘source tree’ ambiguity stems mostly from that source in developing are used to describe a lot of different aspects, and that a source tree in some form/kind are something most IDE and some text-editors has. In this survey a source tree was supposed to represent a tree of the code you where currently writing (see image), but a source tree may in many occasion mean a list of files in a project. Also called a ‘project tree’ or project source tree’. In Eclipse a source tree in our context is called ‘outline’. This may have been better to use, and would probably made for less confusion. Other viable terms are abstract syntax tree from compilers, or just plain ‘code tree’.
How did the survey go
The survey in it’s whole can been seen in attachment X and thee answers are in attachment X. The first question was addressed in the previous section and will not be repeated. So I will list up each question and discuss the answers given. This is to make it more clearly and straightforward.
- What is your text-editor or IDE of choice?
This was a question where the user could tick off each editor they used, and add more if they wanted. Over 40% of the participants used Eclipse, but Emacs and Vim was close behind. That which where interesting was that 36% of the users tick of for other, and half of them said the used Sublime. This very interesting since this is a fairly new and up-and-coming editor. The rest of the editor was well distributed.
- Does your choice of IDE/text-editor support one or more of the following features?
Next question was more of a control question to see if the features we expected to be important to implement in a new editor. And our believes where confirmed by the answers. Nearly all of the features where used by at least 75% of the participants, and only source tree and refactoring where less then 70%. As discussed earlier, this is probably because of the ambiguity in the words.
- Which of the following features do you think is necessary for an IDE/text-editor?
To find out what people would want in a new editor, we asked what features they felt was necessary. These answers lined pretty nicely up with what features the editors/IDE they already use supports. It also lines up with what features they use, which can been seen in the next question. One participant also stated;
”All the rest is very usefully but syntax highlighting is the only one I can not be without”
- Which of the following features do you use when you develop?
Last question was about which features they used when they developed, and how much they used each specific feature. As predicted most of the features where frequently used, and as previously questions show, ‘source tree’ and ‘refactoring’ where the two that was least used. This, again, can be either because of misunderstanding of what the survey meant, or that they just didn’t use it that frequently. ‘Code completion’ and ‘Code suggestion’ had also nearly the same answers, which is likely since most editors/IDE that have code suggestion, also support code completion. ‘Error-reporting’ on the other hand has a more divided feedback, where nearly 30% says that the use it all the time, but another 30% says that they use it rarely (which is indicated by a 2 in the survey). The remaining 40% was spread between ‘not used’, and ‘uses’. Compared to what kind of editor/IDE participants uses, the distribution between ‘uses all the time’ and ‘rarely used’ is comprehensible, as Vim and Emacs (which more then 55% of the participants uses) does not support error-reporting by default. As they don’t have any understanding of languages without modes or scripts.
To supplement to the last question, there was a text-box for the participants to add features that they did use, but was not present in this survey. A common denominator of the extra features used are that they are complex and split between different tasks. Also none of the participants mention the same feature.
Some of the more difficult and complex ones, which where not tied to language specific features, where; debugging, version control, plug-ins and plug-ins manager, code optimization (footnote: similar to real refactoring), and macro-recording.
Features which are possible with the RSTA framework; definition jumping, diff view, source link (footnote: accessing other files via ctrl-click), keyboard shortcuts, code generation, dynamic templates, and split window.
There where also mention of features that are already functional in RSTA, which where not mention in the survey. They are as following; automated indentation and tabbing. Both of these could have been added to the survey, but where forgotten.