I'm not sure this article is really saying too much at all. I started with extreme programming back in 99 (after following the proponents and all the heated discussions on the most brilliant OTUG email list)<p>Many many times I have seen this kind of question, "Aren't we just making this too complicated?"<p>and the response being "It's not complicated, if you misunderstand X Y or Z you are probably going wrong"<p>My observation is, many things of the things we leverage in the software world are answers to problems. Some of those answers seem so good, and work brilliantly when combined with other answers we package a set of answers as a "process / methodology" and advocate it.<p>But sometimes for some people the answers don't really match the problem, or need adapting to the problems at hand. Now, without good insight into the original problems, then YES it will be "too complicated". Any time you do things for problems you don't really have it is<p>A phrase that was thrown around in the early days of XP was "Brain Engaged", to try and highlight that you don't blindly do things, you need to be aware why you are doing something and adapt as necessary.<p>However! If someone says "hey this new new way of approaching design is awesome", and it piques your interest, You <i>should</i> blindly learn/try that something new and debug it till you get an understanding of why it was considered awesome. At that point you can brain engage it as needed.<p>So back to the original question, yes, we do make things too complicated and we shouldn't do things that don't make sense. It may not make sense because we have the knowledge and experience to know it doesn't, or it doesn't make sense because we are too inexperienced. Both are valid reasons to stop and start asking what is going wrong? why isn't this working? In the world of "Lean" this is the idea of "Stop the line", sort things out, start moving forward again, even if slowly at first.<p>All that doesn't mean you should keep things really basic without changing, it is very important to know how to adopt ideas for doing things better and that actually contribute to things we care about.<p>Also important to try not to become a cynic, eg, "tried microservices, they suck, OO sucks, imperative sucks, VB sucks, NoSQl sucks". When we become cynical of something it becomes very hard to be brain engaged in regards to them. Also the opposite is true, becoming enamoured with something can limit our brain engagement also like "Functional program all the things!, unit test all the things!, scale all the things! deep learn all the things! distribute all the things! Reactive all the things! things! the all Forth"