4 ms·

I try to explain this to people all the time. People discount tribal knowledge. I always use the analogy what if we where hired to build an app for Islamic bank

by kls 6y ago

I try to explain this to people all the time. People discount tribal knowledge. I always use the analogy what if we where hired to build an app for Islamic banking, and ask them do you know anything about Islamic banking usually the answer is no. I know one thing about Islamic banking, they are not allowed to charge usury and I think they charge an upfront fee. I don't know how it is paid or if it is rolled into a loan, but the point is, someone who is from an Islamic country would know this, just like I know a US loan is going to be amortized with compounding interest that does not compound. Though I am not a banker, I have tribal knowledge of this contract. This filters down to very simple things that people take for granted.

kirubakaran 6y ago
A programmer from the US won't know the nuances of US banking either. I agree that someone has to know and write the specs. Does it have to be the programmers? I agree that domain knowledge is invaluable. But in the examples given, the difference in domain knowledge between local talent vs remote may not justify the 5x salary.
- constantine42 6y ago
  The problem with any outsourced companies is they live and die by acceptance criteria. Many times it takes longer to write out all of the criteria to the level of detail that I need than to just do it myself because natural language is horrible for such technical details and trying to explain to someone "What" and "why" is too time consuming. It really bothers me because I generally get put on projects with little acceptance criteria and not something I've done before, yet I deliver on time and the end user is very happy because I take the time to ask good questions up-front. Why can't someone deliver something that makes me that happy. On the topic of communications. I've consulted on projects where I've said that something I noticed should be done a specific way, even though it was not part of AC, technically worked correctly, and making the change would be feature creep. My advice was ignored. Weeks later the end users kept complaining that the software was difficult to use and could not communicate what they didn't like. Since they refused to use the software and they refused to accept it as it was, I was brought back in. I sat down, found out what work the end user was doing, and did some of that work. I literally did someone else's job. I used the software. I made a huge list of areas for improvement. The PM agreed to everything. All of the changes were made, the end users were now saying it was awesome to use. To summarize, learn to read between the lines of the acceptance criteria. Would you want to use the software you're making? For me, small issues annoy the heck out of me. I notice these things. End users tend to just say nebulous things like "it doesn't work well".
- PeterisP 6y ago
  I've worked on banking software development, and we definitely expect programmers to know nuances of banking. Perhaps not all the nuances, and many aspects are arbitrary choices and only the spec would reveal what the business unit chose, but there's a lot of domain knowledge required to be productive. If we need to outsource stuff, that has to be to some outfit that has developers experienced with banking nuances, and often times they are more experienced than internal devs (because they have worked on this parictular tricky corner of banking for multiple different institutions), and if we hire devs from outside the industry, we expect the first 6 months to need a lot of handholding because they don't know the nuances of banking and they can't be productive at all until they learn at least most of them, because no realistic spec will be sufficient for a programmer without a domain knowledge, at least not in the financial domain.

by kls 6y ago

kirubakaran 6y ago

A programmer from the US won't know the nuances of US banking either. I agree that someone has to know and write the specs. Does it have to be the programmers? I agree that domain knowledge is invaluable. But in the examples given, the difference in domain knowledge between local talent vs remote may not justify the 5x salary.

constantine42 6y ago
The problem with any outsourced companies is they live and die by acceptance criteria. Many times it takes longer to write out all of the criteria to the level of detail that I need than to just do it myself because natural language is horrible for such technical details and trying to explain to someone "What" and "why" is too time consuming. It really bothers me because I generally get put on projects with little acceptance criteria and not something I've done before, yet I deliver on time and the end user is very happy because I take the time to ask good questions up-front. Why can't someone deliver something that makes me that happy. On the topic of communications. I've consulted on projects where I've said that something I noticed should be done a specific way, even though it was not part of AC, technically worked correctly, and making the change would be feature creep. My advice was ignored. Weeks later the end users kept complaining that the software was difficult to use and could not communicate what they didn't like. Since they refused to use the software and they refused to accept it as it was, I was brought back in. I sat down, found out what work the end user was doing, and did some of that work. I literally did someone else's job. I used the software. I made a huge list of areas for improvement. The PM agreed to everything. All of the changes were made, the end users were now saying it was awesome to use. To summarize, learn to read between the lines of the acceptance criteria. Would you want to use the software you're making? For me, small issues annoy the heck out of me. I notice these things. End users tend to just say nebulous things like "it doesn't work well".
PeterisP 6y ago
I've worked on banking software development, and we definitely expect programmers to know nuances of banking. Perhaps not all the nuances, and many aspects are arbitrary choices and only the spec would reveal what the business unit chose, but there's a lot of domain knowledge required to be productive. If we need to outsource stuff, that has to be to some outfit that has developers experienced with banking nuances, and often times they are more experienced than internal devs (because they have worked on this parictular tricky corner of banking for multiple different institutions), and if we hire devs from outside the industry, we expect the first 6 months to need a lot of handholding because they don't know the nuances of banking and they can't be productive at all until they learn at least most of them, because no realistic spec will be sufficient for a programmer without a domain knowledge, at least not in the financial domain.