Me and my brother wrote our first commercial videogame in 1987 as a 16-17yo pair of self taught programmer/artist/designers. We just did what seemed like common sense.

- We had periodic meetings with the client (publisher). we showed them progress and they suggested directions to move towards

- We didn't stick religiously to the initial design, and adapted as we saw things work or not work to make the game fun

- We stuck to the deadline and just cut what didn't make it

It felt quite agile to me.

Slightly OT: The biggest collective fiction today is probably this idea that as tech person, we can change the world, and as a result we should try to change the world. Anything less impactful feels like a waste of potential. The general society has bought into it - because we've been hearing this for years: Johnny - you are such a smart programmer, where is your world changing app ?

Among other things, this translates into working ridiculous hours in expensive cities and convincing a set of investors that they too can be part of this world changing process in exchange for a few shekels. Now these shekels will drive innovation, and they will push civilisation forward.

But the magic of the fiction is that poor Johnny will never feel like he did much to change the world, and so he will keep trying ad infinitum.

Good writeup :)

I did the whole rollercoaster only for 11 years now, but I also was in different companies from startup to big corp.

Some people are totally into their methodology and won't do a step aside the predefined path.

Some people are totally elusive to process. They will talk to you via email, Skype, WhatsApp and JIRA and you won't find any infos later.

I have the feeling there is no methodology for devs to work better, only for devs to get peace from non-devs who work with them.

Having lived through a variety of methodologies, all of which were taken very seriously and equally successful, this rings true.

The one thing I would maybe add is that the tools of the trade have changed for the better in thirty years, particularly source control management, document tracking, and the ability to collaborate remotely. I think ways of development have changed in response to that.

Imagine a world where compiling a build of a piece of software took as a long as an hour, source code was stored on a single server so that you didn't even want to have two people working on the same set of code, automated testing didn't exist.. I can remember cases of that in my youth. It seemed to call for more planning and a more top down approach.

I'm not sure I have any particularly strong views to share, but a couple of notes.

I felt like "collective fiction" was a harsh term that implies we're always lying to ourselves. While that might be true, I like to use the more ambiguous term "narrative" for the same concept. The need for a methodology is a narrative or story that may or may not be true. I guess I do believe ;) that some of our collective narratives are definitely true, and calling them fiction undermines the good ones, or at least makes it harder to evaluate which collective beliefs are more valuable & closer to truth and reality than others.

Side note - collective narratives are a human condition, not in the least limited to programming methodologies. We build collective narratives for everything, and our physiology is prone to it. Having kids, it was fun watching them repeat stories they hear about the world over and over, as a way to cement their narratives with their friends and parents. When they were younger it was almost in the form of a question, they were waiting to be challenged or get more specific information. As they grow older, they get more firm in their statements and beliefs. After watching them do it, I became more aware of how often adults do the same thing, and how pretty much all communication, even technical communication, is just narrative.

My own 20 years of experience with methodologies and with other programmers has led me to believe that pushing coders to communicate frequently about what they're doing and what needs to be done is a good thing; most programmers I've known (including me) tend to wander in directions that they want to go and don't naturally want to do all the things that really need to be done. I sometimes don't like being transparent about what I'm doing, sometimes because I'm working on a pet project that I shouldn't be working on, sometimes because I hate budgeting and I don't know when I'll be done, sometimes because I want to deliver a higher quality than was requested and I know I'll be asked to stop being a perfectionist and just check in my changes. I see others not wanting to be transparent about what they're doing for the same reasons. But making sure that transparency exists is probably the only thing I've seen that works. Checking in often, making sure incremental progress is going the right direction, and re-iterating the requirements and users' point of view.

Too much formal process is usually bad unless you're NASA, and by the time it's called a "methodology", it's probably too much. It gets in the way of a lot of the good things that need to happen. Two week sprints get exhausting after a while, it teaches devs to aim smaller, and it causes undue burdens from management on tasks that legitimately take a couple of months. Being forced to estimate everything in story points has some advantages, but ultimately makes measurement harder, it's subjective and easily manipulated, and it's just contrived anyway.

So, I agree about formal methologies not working well, by and large, but I think the basic intent to keep focused and communicate frequently are good goals. It is ironic that most software methodologies are reasonably good at helping people evaluate how to make certain kinds of focused technical decisions, but they're very bad at helping people evaluate when a formal process is wasteful or bad, or to suggest a different formal process.