Definitely. An awful lot of programming is "Take data from place A (in format 1) and place B (in format 2) do magic thing J to it and put it in location Z (in format 3)".
Process J is usually the simple bit - the hard bit is taking it from A and B, converting (1) and (2) so that they can be used together, dealing with all the different eventualities that can cause things to go wrong when fetching the data, parsing the data into (3) and then writing to Z (while dealing with all the things that can go wrong when writing to it).
"Yeah, meanwhile Z is temporarily unavailable and by the time it's available again, the data from A and B is no longer consistent, so you have to re-query again, ouch, your pointers to last read data on A are no longer valid anymore and yeah, we forgot to tell you this little funny thing about B... <the dramatic music in the background pauses here>" - this is what you should be thinking when looking at a small arrow drawn on a whiteboard.
In my experience in Big Freaking Enterprise development, the issue is closer to "this little funny thing about B" x 100, plus "group Q doesn't want this project to succeed", "you have to be compliant with Regulation F which means, most relevantly, that all good technical solutions to this problem are legally forbidden", "your success with this will threaten the budget of the Z department -- be prepared for a knife fight with the VP", "group P will veto the project if it is delivered with property G and group R will veto the project if it is delivered without property G (bonus points awarded for values of P equal to R)" and "by the way, this doesn't advance an actual business goal."
The technical details are usually pretty boring. Data goes in, data comes out, if it weren't for all the bloody people involved it would be very civilized.
I spent over two years trying to get the contents of a single dropbox on one form changed. Coding time, about 10 minutes. I guess if you want to look on the bright side you can think about how much political weight a single HTML element can carry.
I don't think this makes sense. If it were true, that would imply that it would be easier to rewrite J to work on format 1, which is the flip side of claiming the conversion is the more difficult part. And if the arrows are more expensive than the components they are pointing to, this remains true for all such arrows, so adding more arrows means it's even cheaper to rewrite J n times than to write n converters; you can't make up the loss in volume.
This sounds superficially appealing but I'm not sure there's any actual wisdom here.
You're assuming that I have any ownership of J, which I don't - it was written to work in a particular pattern that the CIO favoured five years ago, before he left to work for a consulting firm.
Also, A is a 30-year old legacy system sitting on a mainframe, B is an Oracle database inherited when we bought over another company, and Z is a third-party who we're shipping data to for their just-in-time procurement system.
"You're assuming that I have any ownership of J, which I don't"
No, I'm not. I'm simply taking seriously the claim that the arrows are more expensive than the components. If that's true, then it's cheaper to rewrite J, period, by definition of the claim at hand.
If it's not cheaper to rewrite J, then the arrows are cheaper than the core components and the way in which they are more expensive is only in an artificial and useless measurement of "cost" that only holds up as long as you don't take it seriously... what's the use of it, then?
The problem there is that there are already several arrows pointing to J. So if I change J then I have to update all of them too. And then have them regression tested.
(It's usually the cost of regression testing that causes the most crustiness.)
Process J is usually the simple bit - the hard bit is taking it from A and B, converting (1) and (2) so that they can be used together, dealing with all the different eventualities that can cause things to go wrong when fetching the data, parsing the data into (3) and then writing to Z (while dealing with all the things that can go wrong when writing to it).