In this article I want to discuss the importance of the relationship you have with your software, the user’s and why when we build big and put the developers further from the customer or the problem, we get broken ever changing software.
--
Everyone at some point in their lives has dealt with software that they wished worked better for what they wanted it to do. We have even all bought software that is marketed as being developed for our niche, but when we opened it we wondered if the software vendor could pick our niche out of a lineup of niches.
We open the software and begin to use it, but find it so cumbersome that we either quickly give up on it, spend hours trying to learn it, or simply complain about how bad it is and begin the search for new software.
So can this problem be avoided? Somewhat. Could software creators produce flawless software that fits everyone’s needs?
ABSOLUTELY NOT!
Does that mean we give up and don’t even try? Do we look at our Business Analysts, UI Designers, Architects and scold them for doing a terrible job?
No! In my experience it is a simple case of a lack of relationship between the coder and either the customer or the niche. You could throw the best UI Designers and Business Analyst you want at a problem, but if the developer still doesn’t know the pains and problems they are solving, then they will struggle to create software that the user absolutely loves!
You see this in the open source world a lot. If you are say a python developer and you pull down some open source tool that a python developer wrote to make their job easier. You bet it is going to be an amazing tool for you as a python developer. The developer understands the problem, the pains, the issues that the common python developer faces on a daily basis with their toolset. However if that same python developer builds a word processor and rarely types up anything more than a few blurbs here and there, then their product will most likely flounder and just cause frustration or lack of adoption. What is unfortunate is this fictional python coder might be AMAZING, the best there ever was, a developer that writes flawless code. But, if that dev never captured the needs of the customer, then what they have coded will die a slow painful death and their code will be butchered and used in other products that better understood the customer.
Now this fictional python developer could have worked with some architects, business analysts, UI Designers etc, and they probably should. But, again not even the best of the best cannot relay to someone who never experienced something how it is. It’s similar to how when parents get frustrated when non-parents give them advice on how to raise their kids. Yes some of the advice is helpful and good, but a good chunk of it probably is garbage for you raising your kid, and if those people decide to have kids, they will quickly realize they are individual beasts all their own with their own requirements and quirks. Software is the same way.
The developer again, could be great, but unless they either Believe in their cause, are a part of their user base, or have deep customer relationships. They will have a harder time structuring a program in a way that makes sense to the people who are actually using it.
So let’s go though those 3 name tags a developer could wear: a Believer, a User, or the Friend.
Believer:
This developer may or may not use the software they write, but oh, does this developer believe in their software. The developer who believes, is a developer who spends their free time and is consumed by the market or niche that their product is serving. They are evangelicals of their tool to save the masses, their tool solves the problem. The developer believes in their tool and the cause they are supporting. They pour so much of themselves into it, they might as well be a user of it. They believe in the dream and they know how to achieve it.
User:
This developer is an actual user of the software they are creating. They know first hand the pain points and what they need their software to do. They understand the problems it solves as they are living those problems. They have a passion for the product, because they themselves use it. When they write the code, they think of themselves and how it would work for them.
Friend (Relational):
This developer may not use it, and may not even care about the product or it’s use case; but this developer sure cares about the User though! This developer will bend over backwards to consume every bit of information the user provides, pouring over things such as their help desk tickets, while even offering solutions to the user while doing so. They have a love for making their users happy, and when the user is happy, they are too. This developer doesn’t sit alone in a cubicle just churning out code, they actively engage the user and gain their feedback and concerns. They want to see the product succeed because they are a true friend of the user. So the user build and seeks advice every step of the way, ensuring the product they build, is what will make the user happy. They have mastered customer service!
--
So what type of developer are you for the products you work on? Is this something you think is accurate and that you want to grow in to write better software?
Personally, this is why I will always struggle with Coding Farms and auto-coding tools. They are just too far away from the customer.
However.... The opposite is true too. You can be too close to the Customer or Niche. Stand-by for a Part 2!
Top comments (0)