> another shaman practice, valuable but without providing guarantees
This is the same fallacious argument you keep making over and over. You dismiss tools that provide guarantees as "not practical," while calling techniques derived from experience "voodoo."
You obviously have no experience in construction or civil engineering, have never looked at a building code book, and generally have no idea what engineering is:
> The day software development has turned into an engineering, you can bet the contractors who get awarded big contracts like the Obamacare web site would make sure they spend the $$$ to apply the practices which have been proven to ensure software projects become successful
Just like Boston's Big Dig.
> MISRA-C: one entry which is just not compatible with the others. So if you are doing a project using C because it's the only practical option
No one in the real world ever has to retrofit or maintain old buildings and infrastructure projects.
> The space of program state is so combinatorially non-linear with regards to the space of its source code (read: entscheidungsproblem) that ensuring 100% line-wise code coverage is just a sad excuse in getting the whole building not to crumble. Better than nothing, still guaranteeing nothing.
Yeah, and finite element models are a perfect representation of the real world.
> Enforceable, auditable process is helpful and necessary, it ensures nothing with regards to the produced code.
I guess all those CAD data management systems don't help engineers design good buildings either.
> Code review: frankly, this is the pinnacle of shamanism in your list. Four eyes see more than two. Eight eyes totaling 80 years of software creation experience are sure going to benefit the quality of the code. I find it indefensible this as "engineering", no matter if you include it in the commit/merge flow. It's just useful but totally fallible common sense elevated to policy.
Just like structural engineering reviews of architectural plans are obviously useless. No way would a structural review by experienced engineers have helped prevent the Kansas City Regency Hotel disaster.
> You obviously have no experience in construction or civil engineering, have never looked at a building code book, and generally have no idea what engineering is:
I have very little experience in a architecture project decades ago, I just described my experience a couple comments above - I haven't claimed any more than that. I don't know what reasonable claim you could have to affirming I have never looked at a building code book - I more than looked at one, implemented in software the rules in there following the direction of an architect, and was generally amazed when I saw how real engineering works. I also spent five years attending an engineering school before working in large "software engineering" projects for 20 years, which I don't think are an instance of engineering at all, but hey.
Enjoy your faith in software engineering, your ad-hominems, your cynicism, and your real engineering career. Good bye.
This is the same fallacious argument you keep making over and over. You dismiss tools that provide guarantees as "not practical," while calling techniques derived from experience "voodoo."
You obviously have no experience in construction or civil engineering, have never looked at a building code book, and generally have no idea what engineering is:
> The day software development has turned into an engineering, you can bet the contractors who get awarded big contracts like the Obamacare web site would make sure they spend the $$$ to apply the practices which have been proven to ensure software projects become successful
Just like Boston's Big Dig.
> MISRA-C: one entry which is just not compatible with the others. So if you are doing a project using C because it's the only practical option
No one in the real world ever has to retrofit or maintain old buildings and infrastructure projects.
> The space of program state is so combinatorially non-linear with regards to the space of its source code (read: entscheidungsproblem) that ensuring 100% line-wise code coverage is just a sad excuse in getting the whole building not to crumble. Better than nothing, still guaranteeing nothing.
Yeah, and finite element models are a perfect representation of the real world.
> Enforceable, auditable process is helpful and necessary, it ensures nothing with regards to the produced code.
I guess all those CAD data management systems don't help engineers design good buildings either.
> Code review: frankly, this is the pinnacle of shamanism in your list. Four eyes see more than two. Eight eyes totaling 80 years of software creation experience are sure going to benefit the quality of the code. I find it indefensible this as "engineering", no matter if you include it in the commit/merge flow. It's just useful but totally fallible common sense elevated to policy.
Just like structural engineering reviews of architectural plans are obviously useless. No way would a structural review by experienced engineers have helped prevent the Kansas City Regency Hotel disaster.