There’s only tiny little fraction of people who ever use software they write. And that’s natural, unless you work on development tools or general-purpose office software. Most likely you don’t.

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?
Right, it’s not that easy to not accommodate yourself to what you work on when you are a software developer. But the fact doesn’t imply you shouldn’t give it some thinking. I remember the story someone told me many years ago about his software programmer colleague developing a form, pretty simple one (about a dozen data entry fields). It was specified overall, what function should perform within that system but the screen layout wasn’t specified. Guess what was the result?.A screen with a dozen of data entry controls… and no “submit” button! Why? Because in order to test it, it was 100% enough to simply press “Enter” on your keyboard.

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.
Alex Yakima
Paul is a software architect for Luminis Technologies and the author of “Building Modular Cloud Apps With OSGi”. He believes that modularity and the cloud are the two main challenges we have to deal with to bring technology to the next level, and is working on making this possible for mainstream software development. Today he is working on educational software focussed on personalised learning for high school students in the Netherlands. Paul is an active contributor on open source projects such as Amdatu, Apache ACE and Bndtools.