3 ms·

> Integrating with ADP is easy, but like so many other enterprise software/platform integrations, each project has to be taken independently. How are those two

> Integrating with ADP is easy, but like so many other enterprise software/platform integrations, each project has to be taken independently. How are those two statements not contradictory? Seems to me that if integration was easy (read standardized) it would be agnostic of, not specific to, who was integrating.

dragonwriter 11y ago
"Easy" is not opposed to "time consuming and tedious". Its quite possible (and common, IME, in programming) for things to be both easy and time consuming, tedious things that need to be done one-off for each particular implementation because you are working with something that, for instance, resists the kind of abstractions that would make it generalizable. Pretty much anything for which recipe-style cookie-cutter patterns are documented, for instance, fits this description.
- eitally 11y ago
  Exactly this. Things like payroll integrations and benefits administration are not obvious and straightforward at any large company. For example, even common things like international transfers or leaves of absence can trigger manual processes at companies that don't have software to do it for them. Integrating with ADP is easy, but figuring out the business logic and process re-engineering is tedious. It's exactly things like this why I think most programmers and architects should spend at least a year or two working in a large corporation. They'll be exposed to all kinds of situations that just don't exist in a startup (or even most SMBs).
devonkim 11y ago
Easy to me means not technically challenging. Over 90%+ of the enterprise integrations in my careers are tier 1 - 2 easy in the context of software engineering knowledge. It's usually a really convoluted form of "fill in the blanks in a form and pray it works." But these are all complicated in that you could literally take the smartest person in the history of the world and make about the same rate of progress as if you had taken a pretty average person to do the same thing. These sorts of problems tend to be related to wicked problems. For example, there's a bazillion side effects to consider, meetings to be had about "what does this field mean to you actually?," and other things that are of business importance but are a complete snore to the programmer implementing them. You're not talking about whether to use singly or doubly linked lists or which datastructures to use in an integration almost ever, but you're talking about how well it will scale from the perspective of a business and how its own rules and patterns of use work. Business algorithms might be something both hard and complicated of a topic, but unless your business is actually something technical such as algorithmic trading, scientific & technical research, etc. your business domain skill level is probably more about depth of knowledge than whether you're really smart or anything in itself. Also, SOAP was a very popular "standard" but those of us stuck in the pits of writing tons of XML-RPC SOAP code for years knows that it was hardly ever more standardized in practice than "REST" is today.

dragonwriter 11y ago

"Easy" is not opposed to "time consuming and tedious". Its quite possible (and common, IME, in programming) for things to be both easy and time consuming, tedious things that need to be done one-off for each particular implementation because you are working with something that, for instance, resists the kind of abstractions that would make it generalizable. Pretty much anything for which recipe-style cookie-cutter patterns are documented, for instance, fits this description.

eitally 11y ago
Exactly this. Things like payroll integrations and benefits administration are not obvious and straightforward at any large company. For example, even common things like international transfers or leaves of absence can trigger manual processes at companies that don't have software to do it for them. Integrating with ADP is easy, but figuring out the business logic and process re-engineering is tedious. It's exactly things like this why I think most programmers and architects should spend at least a year or two working in a large corporation. They'll be exposed to all kinds of situations that just don't exist in a startup (or even most SMBs).

devonkim 11y ago

Easy to me means not technically challenging. Over 90%+ of the enterprise integrations in my careers are tier 1 - 2 easy in the context of software engineering knowledge. It's usually a really convoluted form of "fill in the blanks in a form and pray it works." But these are all complicated in that you could literally take the smartest person in the history of the world and make about the same rate of progress as if you had taken a pretty average person to do the same thing. These sorts of problems tend to be related to wicked problems. For example, there's a bazillion side effects to consider, meetings to be had about "what does this field mean to you actually?," and other things that are of business importance but are a complete snore to the programmer implementing them. You're not talking about whether to use singly or doubly linked lists or which datastructures to use in an integration almost ever, but you're talking about how well it will scale from the perspective of a business and how its own rules and patterns of use work. Business algorithms might be something both hard and complicated of a topic, but unless your business is actually something technical such as algorithmic trading, scientific & technical research, etc. your business domain skill level is probably more about depth of knowledge than whether you're really smart or anything in itself. Also, SOAP was a very popular "standard" but those of us stuck in the pits of writing tons of XML-RPC SOAP code for years knows that it was hardly ever more standardized in practice than "REST" is today.