Thanks a lot for your ¿review? :-)
As you have noticed, the article has indeed a bias towards the most common form of modern software development.
For example, when you comment about doing something that drives industrial equipment, the rules change. Basically because rules changes. Software was created to be easy to change, in contrast to hardware, so, the idea of Agile came to harness this capacity in an even less limited form of Lean. But, industrial equipment is hardware, hard to change. So, in this cases it is better to do it right the first time. Also, the possibilities and functionalities that may have in the future are constrained by the physical limitations of the hardware itself. So, yes, in this cases methodology is very different, because software-and-hardware aligns into a single methodology. In fact I had some experience consulting software development of one piece of software that controlled a machine, in which one bug, could blow up the entire factory plan. So yes, here constraints are different. Yet, that experience was before I discovered TDD, so... I do not know what I would have done today.
About Toolkit A, B, ... E on the one hand, it is often solved by standard software and architectures that have been proven to be solvent uncountable times. Also, I have to say that I have seen mostly waterfall projects fail because of the choosing of the wrong tool or the wrong code design.
But, it feels more like the «Wouldn't be easier to do it right the first time» that Kent Beck comments in this interview. The problem, is that doing right in the first time is a fallacy because the first thing that happens is that while you are developing, someone comes with a better idea, and changes the objective, and that breaks your intended architecture. Numbers (from a research paper that I always lose the link) have shown that the bigger is the project, the higher is the probability of failing, having around a 90% probability of failure for projects larger than 1M$ (I just found one source that is called Chaos Report by Standish Group, but it is not public :/)
After years of experience, I have discovered that it is best not to over-engineer and leave some possible future runaway out, than adding things that later will increment the maintenance cost. Although, you are basically describing the firsts weeks of development, which I feel that it is fine, although that a little bit extreme. Performance, it is not often a big problem nowadays, but maintenance cost is. Yet, the biggest problem is going out to the market and no one liked the solution. And in that niche, I have found plenty of business people who see themselves as all-knowing-gods, that start writing a long list of features without knowing what would happen. Also, a good example of a development step by step is the one explained by Robert C. Martin of how he, and his team, created one of the first Wiki software with TDD, leaving out the database. I cannot find the source, but I remember that he said that they only introduced the database in the end, because one customer demanded it for no technical reason. You may know that for a long time, common software was created around the database, and the waterfall design always started creating the database entity model. And because of that, Robert C. Martin always says that forget about the database, «the database is a detail». Well, that is the kind of detail that might delay a project even more. Anyway, often these kinds of problems that you describe are common with junior programmers —senior programmers have been through the wringer—, but, it is better for them to develop a strategy to refactor quickly code, than trying to guess the right architecture (almost sure doomed).
Also, there is a missing piece, that I did not put because the article was to extend. DDD. DDD is also based in the concept that code design and developer work is directed by business. In short, we have been creating and debugging business structures for centuries, so we can take advantage of them. So, somehow, it turns out that leveraging on business is good.
And another missing piece that was the one that I wanted to originally write is a course that I did to teach "TDD/BDD/...". In which I was doing variations year after year, and the last edition was doing one by one scenario. It was incredible and worked incredibly well. Also it was the first time that the students (juniors) really appreciated the methodology. Furthermore, seeing the projects growing PR after PR quickly during months was incredible. Yet, I gave them as a basic platform a back/front already working with basic features implemented, and a guide about when and how to refactor in later stages. Meanwhile, I often do a very close approach to the one presented, although I combine a few Scenarios, basically because the PRs need approval, and that slows down all the process.
So, I do not know if I help or not. I guess that the problem is more addressing to those that are more willing to follow Waterfall than getting closer to Agile. I have been trying to solve that for a long time, I say to myself one step at a time, and yet I do not have discovered the sequence of forty-two words to fully understand what Agile (and software engineering) is really about. Meanwhile, I will continue writing to challenge what we often assume and go one step further.
