Feedback for software development: Introduction
“More the eyeballs, shallower the bugs”
This is a multi-part article where the content is split up in three parts, as I discuss about introduction to feedback, its importance and forms in Part I. Part II will tell why is it essential for developers to record feedback, while part III will tell how providing feedback will help the user get software that’s more suitable, generally speaking.
Before I head on to the article series, there are a few assumptions that I want to admit that I am making. This article is written with an inclination to make it easier and hopefully interesting for the readers from a non-technical background to be a part of software development by discussing ways and importance of letting the software authors know what is desirable and what is undesirable of the software. Thus feedback in this article series is assumed to be of plain text nature, no code expected. mailing list, reviews, twitter and the likes. Another important assumption made here for simplicity is the distinction made between software author/developer and the users. In FOSS, the distinction is blurred out, but taking that into account I feel would lead to confusion and extremely unweildy large article. This might give an impression that the article is geared towards single-author (often freeware but not free software) software, but that is a coincidence as even open source software needs feedback of this kind and in fact they just make it more natural and obvious.
what is feedback in the context of software development?
In simple words, its the reaction to the product, to the software. It includes the positive appreciations and encouragements for further enhancements as well as the negative remarks and the criticisms about current weak spots of the software. Feedback is what gives meaning to a software. A software is only as significant as a user would interpret its usefulness and application. Listening in or reading in on all kinds of feedback from users and peer authors alike right from the start and as often as possible is crucial for a software product that its author intends to keep in the interest and attention of people for a very very long time. If you, dear reader, do care about the software you use and could spare a moment to write a line to the software author(s) of your favorite software(s), go ahead and write it today and send it asap. Its a start, you can attempt before you head on to communicating more of your observations about the software and what you feel is perfect or not about it.
Why is feedback needed at all?
- Importance :- Feedback about software hereby including both client side software, (e.g. desktop apps, mobile phone apps) and web services, (e.g. flickr, wordpress, netvibes) is as important to the software as the reason why the software exists in the first place. If the software author writes it just for himself/herself, he/she is responsible for feedback for the software alone. Often in this case, feedback comes out implicitly, whereas if the author developed software for his/her near and dear ones, feedback need or not be explicitly asked from the users who may be more generous than some stranger in providing useful feedback. Finally if software author is writing a software for the whole wide world (WwW), feedback becomes essential in determining the roadmap of future releases of the software as without it, the author could be writing lines and lines of code, without even 30% of it making any sense to the domain the application is written for. Feedback as always includes even the author’s perspective.
- Dialogue :- When feedback is sought and received from users, a dialogue of sorts gets started wherein users participate with observations of what’s going off-track and ideas and the author responds with edits to his software incorporating ideas and providing solutions for the observations. Dialogue helps a lot in focussing the developer’s efforts in the right direction as user responses helps determine what functionalities of the software are to be prioritized on. It helps better interpret what way a user applies the software to his/her problem as well as what way of doing a task in the software is most comfortable for a user. User responses are never unanimous, so authors ultimately need to decide. Even consensus need not be the smartest decision.
- Motivation :- At a point when the author’s feedback itself gets exhausted and the assumptions to accomodate whims and fancies of imaginary users keep piling up, writing and improving the code, becomes a very tedious and often demotivating experience for the author. Feedback plays an important role in charging up the author with the excitement of focussing his/her efforts for fine-tuning the code in a way that benefits a lot of people in the WwW besides himself/herself. Even an appreciation for the efforts put in so far, would make the author’s day and make it seem worthwhile for him/her to put in further efforts to not only improve the software but to even add on more relevant features.
I hope to put up the next 2 parts soon enough. Meanwhile do remember feedback is what keeps the author going and that stands absolutely true for this blog author as well 🙂 Comments are most welcome and eagerly expected. Keep in touch.
Filed under: software | 3 Comments
Tags: community, feedback, software