2 ms·

The author doesn't have a strong grasp of what software takes to create nor the regulatory hurdles that are put in place to get software into the healthcare ind

by hvs 6y ago

The author doesn't have a strong grasp of what software takes to create nor the regulatory hurdles that are put in place to get software into the healthcare industry, but there's a kernel of truth here. Software developers (and software development companies) understand their problem space _intimately_ and they are the best suited to solve it. Every other field requires additional domain knowledge besides software development knowledge. This is also why the best way to increase your value as a software developer is not to learn new technologies but to increase your domain knowledge of specific industries. Good developers are problem solvers not "coders". (Of course you still have to learn new technologies constantly as well. That's unfortunately the nature of the industry.)

Koffiepoeder 6y ago
This sounds like excuse making to me. In the past few years I've noticed that in order to get a good product one of the most important things is just to say "no, but" to your client. Many software teams just do whatever the client wants without challenging their ideas and beliefs - after all the client knows best. Well, the client knows his business best, but sure as hell they do not know how to make software best. Out of experience I have noticed that a good great deal of managing my projects is just educating the client and giving them advice. This ranges from technical advice to UX/UI advice to concerns about software quality attributes like maintainability, verifiabilty, integrity, reliability,... You get the picture. If you manage to keep this communication line open, I've noticed that it is indeed possible to make great products. But it does require courage, independance, ideation from your side and careful communication.
- jeffreygoesto 6y ago
  What worked well for me so far is asking "why" and "what do you want to achieve" (in the business domain, not technically), almost until it hurts, taking the client by the hand and walking slowly backwards together until we have a common understanding of what the real task is. Many times it was buried under layers of semi well thought out "solutions". The hard part is building trust that you really want to solve the problen together and not let the client lose face. I can wholeheartedly second your last paragraph!
- cmroanirgo 6y ago
  > This sounds like excuse making to me Isn't it better to have knowledge of what your clients are talking about? Having written for diverse groups: games to finance to embedded, it's always best to know the direction your client wants to go. A good developer knows how to deliver product that works for the client, rather than swamping them in technical minutae. Knowing the business properly, you can get them excited about opportunities that arise as a result of knowing their domain enough to give them a competitive edge. They will love you, your product, and be happy to come back for other projects.
- bpyne 6y ago
  "Well, the client knows his business best, but sure as hell they do not know how to make software best." My "clients" are all internal. As I work with more departments, I realize how little they know how they operate. They understand well what their mission is. But the processes and exceptions are largely in the minds of one or two people. My team modernizes legacy integrations between core systems. The departments had a lot of retirements. The retirees took the knowledge with them and left sparse documentation. As I go, I'm trying to develop business requirements documents for them. But it slows down projects. So, I'd say you're right that clients know what they do but not always how they're doing it. I have a feeling that it's not just my organization experiencing this issue.

by hvs 6y ago

Koffiepoeder 6y ago

This sounds like excuse making to me. In the past few years I've noticed that in order to get a good product one of the most important things is just to say "no, but" to your client. Many software teams just do whatever the client wants without challenging their ideas and beliefs - after all the client knows best. Well, the client knows his business best, but sure as hell they do not know how to make software best. Out of experience I have noticed that a good great deal of managing my projects is just educating the client and giving them advice. This ranges from technical advice to UX/UI advice to concerns about software quality attributes like maintainability, verifiabilty, integrity, reliability,... You get the picture. If you manage to keep this communication line open, I've noticed that it is indeed possible to make great products. But it does require courage, independance, ideation from your side and careful communication.

jeffreygoesto 6y ago
What worked well for me so far is asking "why" and "what do you want to achieve" (in the business domain, not technically), almost until it hurts, taking the client by the hand and walking slowly backwards together until we have a common understanding of what the real task is. Many times it was buried under layers of semi well thought out "solutions". The hard part is building trust that you really want to solve the problen together and not let the client lose face. I can wholeheartedly second your last paragraph!
cmroanirgo 6y ago
> This sounds like excuse making to me Isn't it better to have knowledge of what your clients are talking about? Having written for diverse groups: games to finance to embedded, it's always best to know the direction your client wants to go. A good developer knows how to deliver product that works for the client, rather than swamping them in technical minutae. Knowing the business properly, you can get them excited about opportunities that arise as a result of knowing their domain enough to give them a competitive edge. They will love you, your product, and be happy to come back for other projects.
bpyne 6y ago
"Well, the client knows his business best, but sure as hell they do not know how to make software best." My "clients" are all internal. As I work with more departments, I realize how little they know how they operate. They understand well what their mission is. But the processes and exceptions are largely in the minds of one or two people. My team modernizes legacy integrations between core systems. The departments had a lot of retirements. The retirees took the knowledge with them and left sparse documentation. As I go, I'm trying to develop business requirements documents for them. But it slows down projects. So, I'd say you're right that clients know what they do but not always how they're doing it. I have a feeling that it's not just my organization experiencing this issue.