Im not sure its a 90-10% split between the importance of infrastructure to business logic code in our case, but I don't think you necessarily need to make the d

Im not sure its a 90-10% split between the importance of infrastructure to business logic code in our case, but I don't think you necessarily need to make the distinction. Something that I've run into a few times is when an FE will come up with a proof of concept that needs to be built out into something more robust, and it takes longer to build it out than to come up with the concept in the first place. This is often because the original POC is more or less a direct translation from pure math, while the real application needs to be worked into a multithreaded program for performance reasons. That often comes with significant changes to the way the business logic gets executed. Software isn't merely a concrete implementation of pure mathematics. It is a logical system that bears some resemblance to math, but has a number of details (hierarchal memory model, network latency, etc...) that make it act quite differently. I think you can iterate on an idea faster and with fewer bugs if you treat it as a software problem from the get go rather than working on the idea and the software separately. For example, I once had a frustrating argument with an FE about why a program he was working on wasn't working correctly. He thought I didn't understand the normal distribution and how the tails never quite reach zero. What he didn't understand is that the computer doesn't care what a normal distribution is supposed to be, if you try to deal with numbers on the order of 1e-100 in a float in c++, it might as well be zero.