Share any useful articles helpful to programming.

Article "A RATIONAL DESIGN PROCESS": http://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit.pdf

I could only stand to read the first 2 sections and beyond that I couldn't make myself continue to read.

This seems to have been written by a manager person. And the best I can do is point you to some of the resources from handmade hero. In this episode Casey Muratori (who is one of the most incredible programmers I have ever seen at work) explains how to do architecture. And I find this to be much more useful than the paper.

He also has some more insights about architecture in this episode, which comes much later in the series. So here you can see what he explained above in action:

If you follow the series beyond the above episode you will see how he goes back to the plan and updates it. Even at this point you might still get the feeling of "why is the developer doing this!", if you are a manager. I guess, that paper is trying to help managers, and I can't say I really care about making the lives of managers easier. If they cannot figure out how to manage, its really not my problem as a programmer to help them. Its their expertise and they can figure it out for themselves.

You can also go to this video (also made by Casey Muratori) for more non-programmerish thoughts on architecture in larger organizations:

I also think that there is an underlying assumption in that paper that programs can be written in a managed way where the management can be removed from the programming and be performed by non programmers. I will ask you to read the introduction of the Graphics Programming Black Book (https://www.jagregory.com/abrash-black-book/). In particular search for this string in the book: "Much heroic programming ensued" where John Carmack is talking about the work that went into writing quake. I don't think any process that doesn't respect this aspect of excruciating rewrites of things that are already working will ever get good programs made. These people are the masters of programming. And if they need to do that, then that must be the right way to do things.

Also, I'm kind of a novice. So take what I say with a boulder of salt. I'm not responsible if you decide to take any of this seriously and then fuckup something.

The article seems to have a similar way of creating the design document as we have to create code. It's describing a similar iterative process where you pretend to know what you want/need (usage code first) and create an interface for that, then go deeper and if you find issue with a previous decision you modify it.

But at the same time it encourages to design everything before starting programming and I'm not sure if they consider that the actual implementation could inform the design.

Also I don't like that they want to pretend that only the last iteration of the design of a system should exist in the document. I find that when I write comments (which is not at all similar to their document) it's often to write some choice I made, why I made it and other things I've tried and that didn't work.

But Simon, why would one want to write these things in a document removed from the programming itself? Usually I find that this kind of exercise quickly diverges from what is actually programmed. This may be because I have never really worked on a team where there were very experienced programmers present (max 8 years). And more often than not, the people who were leading this kind of exercise had not programmed in years, and were not going to be involved in the programming either.

So, the issue I find with trying to do this kind of design first approach, is that the people involved in this exercise are never able to predict what will happen once they start programming.

I find this kind of unpredictable change happening even in handmade hero where Casey Muratori first came up with the approach of low and high entities and then later switched to sim regions with just sim entities. And again with how the code for moveEntities was changed over time when he discovered better ways of doing things (like the movespec).

I guess what I'm saying is that I have never seen any evidence of such a process working, except when the design is concerned with something like business logic (like a customer comes and logs in to a system, then they go to system y and do something which then takes them to system z).

I guess, some companies have to do this kind of work because their work is just business logic and very little programming is done there. The programming in those places is just scripting to connect existing systems. I think I have only worked in companies like this so far. And I'm hoping I can eventually get to some place where I can program like Casey Muratori programs on the stream. And then I will not have to be a part of all the frustration that comes from a process such as the one described in the paper.

I'm not saying it's a good way to do things.

I haven't work on any system of that magnitude (I'm assuming this article if for big productions), and you have more professional experience than me (since I don't have any).

But I wonder how would some company start to work on a big project like an OS ?

I can't say I know of a winning strategy. I can see that in the companies I have worked at so far, I have not seen one that worked flawlessly.