No, I'd like you to read the whole of it. Or, at least, every author lies to themselves that they have the most devoted of readers.
But yes, you are right with your summary. It is based on an observation that some of the solutions I've seen developed are developed inside our own heads only. Or are written down in documents or slack channels or meetings where we talk, we agree on things but they are not enforced anywhere. Or where we dream "what if's" scenarios, put all those side by side and vote, based on our power of imagining the outcome, and decide what to next implement and spend our time with.
And part of the problem, and I say part as I don't have access to everyone's environment to see how they work at their computer now that we work from home, but part of that is a real fear of the computer (or lack of mastery, I donno), thus the bits about changing code often, some ideas on how to achieve that and make the environment you're using to write code, explore the project and your ideas your own, regardless of how it looks from the outside.
As an extreme example, one client was sending us both the authentication library as .c and .h files to be compiled on our side and an add-on to be installed on a tool we were already using. When there was a new version of the .c and .h files, which always happened as this authentication feature was under active development, the add-on changed too. There were instructions as PDF files on how to install this add-on, which were slightly different every time. When the project started up, before one could send any commands to it, the authentication procedure had to be successfull.
My thinking was that, since I don't work on that part of the system and the features that I'm responsible for only work after the authentication was successful anyway, I can identify the part of the code that does the authorization and hard-code an authorization successful implementation, which was simply returning <q>true</q> from the correct
function. I would thus reduce the number of steps needed to reload the system after a code change and thus reduce the reload time. In short, I would just assume the authorization worked and concentrated only on my stuff. I didn't commit this code, of course. But to my surprise, even though I've presented this to colleagues and even PM, the reply was that well, we sorta have to work with the whole system and make sure the whole system
works. And yes, we did that, only on our daily activities we didn't have a reason to test the authentication part every single time, dozens of times per day since we didn't change
it, we worked on the part of the code that comes after authentication. But no luck. So a lot of time was spent and is spent with these steps.
I say "an extreme example" as automotive software seems to e to be a special example. I wrote about it on another post on my blog. It got pretty long and uncovered all the messiness. But that's another topic.
I have a problem similar to this but not exactly the same. What I would like is for the whole company (assume a run off the mill ecommerce store for this example), regardless of the company size to be able to fit all (I guess almost all) their code on one physical machine (or I guess a set of physical machines). Let's assume we can stub out any external dependencies such as vendors or customers.
We should be able to run the whole system end to end and have a coherent story. We should be able to pull changed from production and be able to run it on this one machine and verify that all the steps work exactly as expected.
I joined a team that was getting into micro services. They enthusiastically told me about their domains and bounded contexts and how I had access to all the repos and could run them on my machine. So my question was how can I run them all together on my machine end to end and the answer was silence as if I had kicked a baby.
Edit: thank you for your added context with the authentication library. It makes sense why the architects and lead developers were not interested in having the whole system run end to end on a developer machine. They want to have that tight "inner loop" and have developers working in that inner loop and not worry about the rest.
But yes, you are right with your summary. It is based on an observation that some of the solutions I've seen developed are developed inside our own heads only. Or are written down in documents or slack channels or meetings where we talk, we agree on things but they are not enforced anywhere. Or where we dream "what if's" scenarios, put all those side by side and vote, based on our power of imagining the outcome, and decide what to next implement and spend our time with.
And part of the problem, and I say part as I don't have access to everyone's environment to see how they work at their computer now that we work from home, but part of that is a real fear of the computer (or lack of mastery, I donno), thus the bits about changing code often, some ideas on how to achieve that and make the environment you're using to write code, explore the project and your ideas your own, regardless of how it looks from the outside.
As an extreme example, one client was sending us both the authentication library as .c and .h files to be compiled on our side and an add-on to be installed on a tool we were already using. When there was a new version of the .c and .h files, which always happened as this authentication feature was under active development, the add-on changed too. There were instructions as PDF files on how to install this add-on, which were slightly different every time. When the project started up, before one could send any commands to it, the authentication procedure had to be successfull.
My thinking was that, since I don't work on that part of the system and the features that I'm responsible for only work after the authentication was successful anyway, I can identify the part of the code that does the authorization and hard-code an authorization successful implementation, which was simply returning <q>true</q> from the correct function. I would thus reduce the number of steps needed to reload the system after a code change and thus reduce the reload time. In short, I would just assume the authorization worked and concentrated only on my stuff. I didn't commit this code, of course. But to my surprise, even though I've presented this to colleagues and even PM, the reply was that well, we sorta have to work with the whole system and make sure the whole system works. And yes, we did that, only on our daily activities we didn't have a reason to test the authentication part every single time, dozens of times per day since we didn't change it, we worked on the part of the code that comes after authentication. But no luck. So a lot of time was spent and is spent with these steps.
I say "an extreme example" as automotive software seems to e to be a special example. I wrote about it on another post on my blog. It got pretty long and uncovered all the messiness. But that's another topic.