> A better solution would be standardize a backend apis and setup standards around how data is queried and stored.
We have actually attempted to do this on a national scale in Denmark because it was silly to have 98 municipalities handle organisational data (and other things) in 98 different ways. So we created something called rammearkitekturen (framework architecture) which specifies what an “employee” is and how you’re supposed to transfer them between systems. The suppliers hired to build this, and these are companies like IBM, Systematic and Netcompany somehow still manage to build things in such a manner that the next company needs to spend a whole year beyond their estimate to get things running after a public procurement process that saw an ownership change. Some of these are complicated, bur most of them aren’t. Or at least they aren’t supposed to be. Now, either IBM is completely devoid of talent, or maybe software “engineering” just isn’t “engineering” at all. At least not on a level that is in any way acceptable to us as enterprise customers.
I’m still not sure why we tolerate year long delays on software projects. It’s not like building a new hospital never gets delayed, but the consequences of those delays are typically bosses losing their jobs and companies paying delay fines (or whatever you call that in English), where as with software the consequences are just a few shrugs and a joke about that pesky IT.
I actually don’t disagree with you as such. My point is simply that when you hire two talented engineers from the same background to build the exact same thing. Then they will both rather easily understand what the other did and how he/she did it, unless it was software.
We have actually attempted to do this on a national scale in Denmark because it was silly to have 98 municipalities handle organisational data (and other things) in 98 different ways. So we created something called rammearkitekturen (framework architecture) which specifies what an “employee” is and how you’re supposed to transfer them between systems. The suppliers hired to build this, and these are companies like IBM, Systematic and Netcompany somehow still manage to build things in such a manner that the next company needs to spend a whole year beyond their estimate to get things running after a public procurement process that saw an ownership change. Some of these are complicated, bur most of them aren’t. Or at least they aren’t supposed to be. Now, either IBM is completely devoid of talent, or maybe software “engineering” just isn’t “engineering” at all. At least not on a level that is in any way acceptable to us as enterprise customers.
I’m still not sure why we tolerate year long delays on software projects. It’s not like building a new hospital never gets delayed, but the consequences of those delays are typically bosses losing their jobs and companies paying delay fines (or whatever you call that in English), where as with software the consequences are just a few shrugs and a joke about that pesky IT.
I actually don’t disagree with you as such. My point is simply that when you hire two talented engineers from the same background to build the exact same thing. Then they will both rather easily understand what the other did and how he/she did it, unless it was software.