3 ms·

When the developer is the domain expert, you've achieved the singularity. /s A large percentage of the time, there is no domain expert available, or there simp

When the developer is the domain expert, you've achieved the singularity. /s A large percentage of the time, there is no domain expert available, or there simply is no domain expert. We've all worked at that place. You start a new job and you're left to your own devices to sink or swim. You wonder why no one can be bothered to take the time to give you the big picture. Who is the customer? Who is the user? Are they the same person? What problems are we trying to help them solve? Are we optimizing for speed, correctness, usability? How do our competitors do it? Who are our competitors? How about some backstory on this codebase? I can look through source history like I'm doing an archaelogical dig. But how about a narrative on why certain choices were made? The reason no one will take the time to answer these questions for you is that they will quickly be exposed as not having answers. The best they can do is say "I'll have to ask so and so", and then you'll never hear back. Also, there is a pervasive vibe that when you're brought on as a developer, it's not your place to ask business-y type questions. Let the people person talk to the people, and you dig ditches where we tell you to dig them. And if we ask you to fill it back in because we told you to dig in the wrong place, well then, you're here 40 hours a week and work is work right? /end rant Sorry guys, my fingers just kept typing.

desireco42 10y ago
Actually this is the most pervasive problem with on-boarding. It comes from lack of understanding of role you will be performing from business side, and from the developer side, mostly tech people who were advanced to role of tech lead, different cto's and vp's have very poor management skills and are just faking it. And all of actual developers are suffering because of it.
wpietri 10y ago
I've never worked at a place without a domain expert. If the company's new, then everybody's aware that they're learning, and so they actively seek expertise. If the place is old, then I've always been able to find people who understand the domain; they've been soaking in it for years. What you're asking for is something a little different, somebody who can feed you a pre-digested analysis, one suitable for understanding/designing the code. That definitely doesn't exist. That person must be us. We understand our domain, computers. They understand their domain, business. They will never understand computers particularly well. So it's incumbent on us to lead the collaboration to create a shared domain model, a formal map of their territory. Of course, some places do try to stop us from working in the ways that are most effective, to treat us as robots. When that happens, the old Agile advice applies: either change your organization or change your organization.
- seanmcdirmid 10y ago
  > either change your organization or change your organization Two different but related meanings coming from two valid parses of the same string, nice!
protomyth 10y ago
> When the developer is the domain expert, you've achieved the singularity. /s agreed with /s but... If your report wr... excuse me... business intelligence developer doesn't become a domain expert, then you are going to have some serious problems down the road. I've seen many developer in enterprise get asked pure business questions because they have to think about them all day long to do their jobs. Its really a strange thing about our profession because in order to program the process and take into account the edge cases you really need to be an expert at the process. Some companies lose their damn mind when a developer knows more about their business than the employee who does the process. I've often found the most trouble from companies with managers that repeat the mantra: "we are not an IT company". That's basically the signal that you will never be acknowledged for your business knowledge. > Sorry guys, my fingers just kept typing. long form is alway good
- OpenDrapery 10y ago
  Funny that you mention that the report writer becomes the person closest to understanding the business. In my experience, the report writer many times is the developer on the team who drew the short straw. So you get this weird effect where the best way to learn the domain is to end up with the least desirable project work (from a dev perspective).
  - protomyth 10y ago
    I ran into a developer that was happy and proud that no report writer could generate a report of a transaction because he did all the calculation on the fly and couldn't be bothered to store some critical data in the database. He basically said that the report writer would have to duplicate the program logic in the stored procedure returning the report data. He was honestly happy and didn't think he needed to take the time to fix it. The report was a customer bill, no report, no money. Yeah, I get any project has tiers, but I have a special hatred for developers who dump on report writers or testers. The developers fancy achievement don't mean a damn thing unless we can get data out of it including billing. Sadly, a lot of the trouble results from a single rule: if a developer cares about the state of a single item when making decisions, be advised that some report writer is going to have to write a report that shows all of the items in the system with that state.
macca321 10y ago
This is why I wish developers would leave test packs with Gherkin specifications behind. The code ends up being the only source of truth without them, and the archaeology has to begin. If developers could just record what they wanted to achieve alongside how they achieved it my life would be much easier. I'm not even asking for the "why".

desireco42 10y ago

Actually this is the most pervasive problem with on-boarding. It comes from lack of understanding of role you will be performing from business side, and from the developer side, mostly tech people who were advanced to role of tech lead, different cto's and vp's have very poor management skills and are just faking it. And all of actual developers are suffering because of it.

wpietri 10y ago

I've never worked at a place without a domain expert. If the company's new, then everybody's aware that they're learning, and so they actively seek expertise. If the place is old, then I've always been able to find people who understand the domain; they've been soaking in it for years. What you're asking for is something a little different, somebody who can feed you a pre-digested analysis, one suitable for understanding/designing the code. That definitely doesn't exist. That person must be us. We understand our domain, computers. They understand their domain, business. They will never understand computers particularly well. So it's incumbent on us to lead the collaboration to create a shared domain model, a formal map of their territory. Of course, some places do try to stop us from working in the ways that are most effective, to treat us as robots. When that happens, the old Agile advice applies: either change your organization or change your organization.

seanmcdirmid 10y ago
> either change your organization or change your organization Two different but related meanings coming from two valid parses of the same string, nice!

protomyth 10y ago

> When the developer is the domain expert, you've achieved the singularity. /s agreed with /s but... If your report wr... excuse me... business intelligence developer doesn't become a domain expert, then you are going to have some serious problems down the road. I've seen many developer in enterprise get asked pure business questions because they have to think about them all day long to do their jobs. Its really a strange thing about our profession because in order to program the process and take into account the edge cases you really need to be an expert at the process. Some companies lose their damn mind when a developer knows more about their business than the employee who does the process. I've often found the most trouble from companies with managers that repeat the mantra: "we are not an IT company". That's basically the signal that you will never be acknowledged for your business knowledge. > Sorry guys, my fingers just kept typing. long form is alway good

OpenDrapery 10y ago
Funny that you mention that the report writer becomes the person closest to understanding the business. In my experience, the report writer many times is the developer on the team who drew the short straw. So you get this weird effect where the best way to learn the domain is to end up with the least desirable project work (from a dev perspective).
- protomyth 10y ago
  I ran into a developer that was happy and proud that no report writer could generate a report of a transaction because he did all the calculation on the fly and couldn't be bothered to store some critical data in the database. He basically said that the report writer would have to duplicate the program logic in the stored procedure returning the report data. He was honestly happy and didn't think he needed to take the time to fix it. The report was a customer bill, no report, no money. Yeah, I get any project has tiers, but I have a special hatred for developers who dump on report writers or testers. The developers fancy achievement don't mean a damn thing unless we can get data out of it including billing. Sadly, a lot of the trouble results from a single rule: if a developer cares about the state of a single item when making decisions, be advised that some report writer is going to have to write a report that shows all of the items in the system with that state.

macca321 10y ago

This is why I wish developers would leave test packs with Gherkin specifications behind. The code ends up being the only source of truth without them, and the archaeology has to begin. If developers could just record what they wanted to achieve alongside how they achieved it my life would be much easier. I'm not even asking for the "why".