How are you doing? Getting feedback
There’s no doubt you want to develop the best software possible. But how would you know how well you are doing? How would you know what to improve? And more interesting, what if it was told to you what you can improve? This kind of feedback is certainly possible! In fact, there are many feedback mechanisms that you can use as a tool to improve software quality. Want to know how? Read on!
Feedback for you
Usually, the word “feedback” is used in the context of soft skills: being able to receive or give feedback. But when you really pay attention, you can also have feedback from many other sources. When you’re developing software, there are lots of possibilities to have feedback. Sometimes you get it for free, sometimes you need to get something in place first. In any case, when you want to improve your product and skills, you should be on the lookout for it and use it to your advantage. Just make sure you pay attention!
In the next paragraphs, I’ll outline some feedback mechanisms that you can use. It is worth noting that some forms of feedback might need some preparation first. Other kinds of feedback are only available when some event occurs. This means that you sometimes need to set things up so that you can have feedback much earlier in the development cycle. Sounds a bit difficult? No worries, the examples will make it clear.
Feedback from your IDE
IDEs are great tools to improve productivity. They’re also excellent to provide feedback very early. For example:
- Code coloring: all IDEs (and even most text editors) do this automatically for you. This not only provides a visual aid to tell keywords apart from variables, but it can help you spot mistakes like forgetting to close a string literal “: this shows the remainder of the code as a string literal and makes it clear that something is wrong. Code coloring happens as you type, so it is the fastest form of feedback.
- Auto completion or intellisense: when your IDE makes ridiculous proposals, you’ve certainly made a mistake. You can also find this out while you’re typing, so it is almost instantaneous.
Note that most feedback is low level: the IDE is great at telling that you made a syntax error, but it does not tell you that you design has a flaw.
Compiler feedback
The compiler can be seen as a feedback tool (and produce a binary as a side effect). Compiler errors are very loud and clear ways of having feedback: if you don’t listen to them, you ‘re just left with no result. The same counts for warnings, although those could be ignored. Still, normally a compiler warning is a hint that you need to improve somewhere.
You can use the compiler feedback to your advantage when you need to do a large refactoring. For example, when you want replace a method by another method, just start to delete the old method right away, then try compile the code. The compilation will fail, but the compiler now tells you exactly which places you still need to repair.
Static code analysis
Static analysis tools are used for different purposes: validating code formatting, finding obvious bugs, showing potential problems or proposing improvements. For example, it can tell you about unreachable code; if you know it is unused, then you can remove it so you don’t need to maintain it anymore. A modern IDE also has static code checks built in, and might combine it with refactoring proposals to get issues fixed in a single click.
I’ve worked with different static analysis tools and, in my experience, it depends on your particular tool configuration how much you will benefit. Different tools have different strengths and weaknesses. Initially, these tools will take a bit of time to set up but when done right, they can be very valuable.
Unit tests
Unit tests can provide feedback in two ways. The obvious way is when you run them; when they fail, it means you’ve broken something. But unit tests can also be used as feedback mechanism when you want to add a new test, because that puts a quality requirement on the code: it must be modular enough so that the unit under test can be instantiated. You can’t do that when your code is tightly coupled, so the fact of just adding a unit test means that you might have to separate responsibilities first.
Interfaces
Interfaces are used to decouple parts of the code. When doing so, the part that implements the interface has some defined responsibility. You can have an idea of this responsibility by just looking at the interface. You can tell from the interface whether responsibilities are well defined: all functions and methods are concerned about one particular responsibility, they logically belong together.
There’s also another feedback mechanism here: if an interface has to change often, then chances are that this interface was not defined so well. It might require splitting up, or maybe some members should be removed from it.
System tests
When the complete application is built, then it is also possible to perform tests on the application as a whole. You can have automated tests to test for regression, or a test engineer can validate the application against the specifications. Both are forms of feedback. They’re important: failing to have this feedback in place turns the end user into a software tester. The end user will get unhappy because of that.
Code reviews
Good code reviews matter. It is not easy to perform a good code review, because it requires a lot of insight in the details of code written by someone else. But it is still a very valuable source of feedback nonetheless, because a good reviewer can provide you with insights that no tool will tell you about.
Integration issues
I’ve seen many occasions where upfront a beautiful design was made, only to discover many issues when getting the software to production. When people get in such a situation, they most often apply fixes and patches until it works. Viewed from a feedback perspective though, the design is almost yelling to them that it is flawed. The sooner you accept that feedback, the more chances you have to fix the design and do a much better job.
The nasty thing about integration issues is that they tend to occur late in the project. If you favor early feedback, it is sensible to have those integration issues as early as possible. You can do that by working in small deliverable increments: first implement the most bare bones version that you can think of and integrate that, then add (and integrate) features one by one. Try to get the most risky features delivered first.
Bugs
Bugs are mostly bad news reports that arrive when you’re not waiting for them. But in some sense, you can also regard them as a form of feedback. That way, you can find out whether there are areas in your code that deserve extra attention, or perhaps a rewrite. Doing that proactively instead of just fixing the bugs will improve the user (and developer) experience a lot.
Continuous Integration
Continuous integration is the automation of the build process: triggered by a code change, it builds the software. You can use it to automate additional validations, so you can have early feedback without needing to run those validations manually. You simply cannot forget them. Continuous Integration is a good tool to run automated static code analysis and unit tests among others.
Customer feedback
The user knows best whether he likes your application or not. Why not talk to him when you have the opportunity? This gives insights in what his problems are, what he is trying to accomplish and in what ways your application is being used. In my experience, almost certainly some surprises will pop up: problems that the user has with your software that you never thought of, or your program turns out to be used in a way you never imagined.
Once you have a sense what the user wants to do, you can often tailor your work towards this and make the software better fit for him. Be aware of the XY problem though.
Production
Very valuable feedback can be received once your application is in production. The art is to get the right information. There are many ways you can have that. As said before, you can talk to (potential) users, but you can also instrument your application and record how it is being used. You can (and should) implement good logging, which helps you analyze potential problems long after the application was restarted. In many situations, you can also monitor production systems and also receive more valuable feedback.
Conclusion
There are many ways you can receive feedback while developing your application. Each way gives you an opportunity to improve, so welcome it and use it in your advantage.
I’ve had many situations with people yelling against the “stupid tools”. That is counterproductive, as you mentally get in fight mode against the tools. Instead, it is much more productive to think about why the tools react the way they do, and see if you can learn from them.