Absent the part about sprints, this describes the majority of professional software development that I've been a part of. Not all of it, but most.<p>There are two sides to the coin of #1. At a certain point, you just have to dive into the problem to actually understand the true nature of it. Some programmers will over-plan things and end up astonished when they actually start coding and find a bunch of edge cases nobody thought of, possibly making those weeks of pontification a waste. I've also witnessed what I think of as "fake planning" where lots of people are roped into a task they really don't need to be a part of, and lots of time is spent verbalizing the problem while providing nebulous solutions. In such cases, someone has to have enough responsibility to start coding and bring others in when necessary, rather than having everyone spend weeks talking up a bunch of waffle so that everything is "perfect" by the time you start writing code.<p>I can actually forgive many of the points of the article, at least in part. #3, #4, and #5 are usually caused either by inexperience or by the business forcing its developers to take shortcuts. I'm not saying I like them, as programmers should avoid using hacks, late testing, and scope creep if they have the ability to. Often times, they don't because of the very system they're working under.<p>The most egregious YOLO development practice on that list is "#6 - No Documentation, No Problem". It boggles my mind how many developers give such little of a shit about the value of others' time and for others to be able to use the code they're writing. This is a big problem I'm dealing with right now, actually. The problem compounds when you give your software team so much to do that they basically don't have enough time to write comprehensive or practical documentation. What makes matters even worse are the teams that think "the code should be the documentation", also known as "my shit doesn't stink." This attitude is one of my biggest pet peeves because adopters will actually scold you from writing inline documentation describing the intent of a function that is otherwise very algorithmic by necessity. What the actual F??? And then these same people ping me when they don't understand my code. It's like, you'd already know the intent of my function if you allowed my inline documentation to pass through code review.<p>And no, API documentation in the form of some statically generated site (which someone has to manage and will inevitably be out of date) is not the solution. The problem isn't that we don't know what arguments a class is expecting. All of that is either solved by IDE hints and possibly having been the one to write the thing in the first place. Your fancy autogenerated API docs tell me little of anything I don't already know.<p>I want documentation, written in the style of a <i>normal human being</i>, that tells me how to get the project up and running and why certain things work the way they do. Is that really too much to ask? Hell, at this point, I don't even care if it's written by an AI. I just want it to <i>exist</i>, to not be woefully out of date, and to act like a source of truth. Don't scatter documentation across inline comments, Github issues, Jira epics, Confluence pages, Google docs, etc. I'm not searching through all that crap when I want to know why a function loops over a bunch of stuff for a reason that isn't obvious, or why we have a concept called "shadow models".<p>Kill "comments make the code hard to read" with a fire. If you don't want to read comments, then use an IDE that can collapse all the comments at once.