Did you ever think about the feelings users have when they use your software?
Pretty fair question, isn’t it? I remember my big surprise of how users comprehend the system you developed… it’s absolutely different from what you think as a software developer or developer manager or product manager… it’s way different. Users do not know or care about how difficult this or that feature was to develop and it thus is not influencing the way they use or think of certain piece of software. They do not care how difficult was it to make this or that feature compatible across different browsers or tuning response time took 2 months. Did you think about what your users really care about? Usefulness… usability… overall product quality…
Here’s a little questionnaire that helps refreshing the understanding of the quality of your work from the end user perspective:
- When using some tool or application, how often did you (as a user, not a software developer) think about “who on earth could develop this… system”? What kind of exact wording did you actually apply to it?
- What’s the best piece of software you ever happened to use? Which of software products that you developed (you think) could be evaluated the same way and people would say that’s their best software system they ever used?
- How often did you think about some software product (say web browser or text editor or anything else…) that it should better do this or that faster or more reliably or more straightforward? How often did you think about your software like that?
I strongly believe there’s always something you can do about the problem. I know what was helpful in the teams I had pleasure to work with as a software developer and I’m glad to share this simple algorithm:
Constantly learn from product managers that specify the product you engineer. Ask yourself questions about the product, instead of just performing your “duty” as a software programmer and write the code. Often use and browse through the entire system you work on, especially scenarios you didn’t develop. Request information about software testing by a us er (if it took place) and carefully learn the results. Participate or even initiate informal discussions about the product, not the code base. Shift the understanding of what you do from software development to product engineering concept. Think in terms of product and place process improvement at the top of your priority list.