We all know that feedback is important. Without feedback, you will never know if you have things done right and you might never see mistakes or problems. Feedback helps us to improve the things we are doing and creating. More importantly, it helps us to improve ourselves. In addition, feedback is more efficient if given directly – in a timely manner. The earlier you get feedback, the more benefit can be drawn from it. Imagine you want to learn a new language. You invest a lot of hours to learn the vocabularies and the grammar by your own. If you do not immediately start to train the new language by talking to other people, you will forget most of the words and the grammar. Talking to other people gives you feedback because you can see if they understand you or even not. At least by their facial expressions. And that is direct feedback – you will react immediately on it and you will learn from it. So, direct feedback is a good thing!
In 1982 Ben Shneiderman proposed the paradigm of direct manipulation for user interface design. Before direct manipulation, the interaction between human and computer mostly relied on a conversation metaphor, e.g. a command line interface which is relatively indirect and abstract. You have to enter your command, execute it and afterward, you’ll get the feedback. Remember back in 1978, TeX was released. TeX is a typographical system that lets you create rich and high-quality text documents. Therefore, you can use a rich set of commands within your documents that arrange and format the text. But to see the final result, you have to run a processor that interprets your input and generates the output. So feedback is relatively late. Here, direct manipulation comes in place. Word processing, spreadsheet applications, and the desktop metaphor were one of the main targets resp. proposals for direct manipulation. Direct manipulation shows the document in its final form and lets you work directly on the objects of interest. You can execute operations on those objects and see the result immediately. So you get immediate feedback on what you are doing. Imagine your today’s word processing application of choice. You can easily select text and change the font, font size, font weight and so on. An image within your text in such an application can be positioned, resized and rotated with the mouse or with your fingers on mobile devices. That lets you adapt and improve your work very fast and, by the way, you’ll learn how the system works. So, direct feedback is a good thing!
When it comes to coding, especially clean coding, what do we have there regarding direct manipulation/feedback? Yes, we have smart IDEs which rich functionalities like syntax highlighting, automatic indention etc. Unit tests validate your code against expected and unexpected behavior but tests have to be run after coding is finished, and so feedback is late again. Tools like NCrunch gives you direct feedback about your unit test code coverage. NDepend gives you feedback about a ton of other code metrics, but that is more or less indirect because NDepend brings in extra tooling and you have to analyze and evaluate the results. Back to clean code: what do we have here? Does your IDE grumble if your methods are too long (LOC is a good indicator for clean code as shown by Prof. Dag Sjoberg)?
Here, Force Feedback Programming comes in. Force Feedback Programming is an idea of Ralf Westphal (the One-Man-Think-Tank) and he introduced the idea on his blog here. The idea behind Force Feedback Programming is to give the developer direct feedback about the code quality while he or she is typing. Starting with the LOC metric we color methods depending on the count of lines. More lines mean more critical colorization. But that’s not all. In addition, Force Feedback Programming means, that the developer must feel the code quality in a visual and tactile manner. To achieve this, noise is generated while the developer is typing. Noise means, that characters are added automatically at the current cursor position. So the developer feels some pain when he or she tries to write code in a method that has too many lines. The amount of noise depends on the number of lines in the method. The LOC metric is a starting point for the first proof of concept. There are tons of other metrics where direct feedback could be given.
With that idea, we bring direct feedback, in terms of clean code resp. code quality, to the developer. Direct feedback is good! But what do you think? Is direct feedback a good thing here, too?
Ralf found me as an expert for Roslyn (the Microsoft .NET Compiler Platform) and Visual Studio extensions. After an initial Skype conference, we brought the Force Feedback project alive – Ralf as the product owner with me as the developer and maintainer of the project. Together, we implemented an extension for Visual Studio to bring Force Feedback to .NET developers. You can download the extension from the Visual Studio gallery or via the “Extensions and Updates” menu in the Tools main menu of Visual Studio. Further, we develop Force Feedback in the wild. You can find the code on GitHub. And if you like to chat with us, meet us in the Gitter chat of the Force Feedback Programming project. We really appreciate your feedback and help. So please feel free to join us on GitHub or Gitter for discussions and further development!
One Video says more…
…than thousand words. So get a first look on Force Feedback Programming in the following video:
With Force Feedback Programming we bring direct feedback, regarding clean code, to the developer. Force Feedback Programming tries to force you to write clean code and if you do not write clean code, you will feel some pain while coding. 🙂 Force Feedback Programming is a Visual Studio extension available in the Visual Studio gallery. The project is open source and can be found on GitHub.
We would really appreciate your collaboration! Please feel free to send us mentions, feedback, suggestions and bug reports. Simply create issues on GitHub or join us in the Gitter chat. Hope to see you there!