Note that the blog post speaks about modules, not classes. It is a bit more abstract and higher level. Note also that the reference to people is mostly to clarify what it means that a piece of software (module or - depending on your design - class) should have one concern/job. The post doesn't say only one person should edit the code or the like. It just says that change to one class should originate from one source and if you go high enough in a company theoretically you can trace that to one person. However, this all just serves to make "one job" more clear - as on an organizational level it is easier to understand that say the department for public relations should make no decision that directly requires a change in the method that calculates money each employee gets each month. They might use the output of said method when trying to hire people but should not change it. If you go out into the real world of company organisation that sometimes makes it clearer what domain an operation belongs to and how to split functionality up.

Note that the blog post speaks about modules, not classes. It is a bit more abstract and higher level. Note also that the reference to people is mostly to clarify what it means that a piece of software (module or - depending on your design - class) should have one concern/job. The post doesn't say only one person should edit the code or the like. It just says that change to one class should originate from one source and if you go high enough in a company theoretically you can trace that to one person. However, this all just serves to make "one job" more clear - as on an organizational level it is easier to understand that say the department for public relations should make no decision that directly requires a change in the method that calculates money each employee gets each month. They might use the output of said method when trying to hire people but should not change it. If you go out into the real world of company organisation that sometimes makes it clearer what domain an operation belongs to and how to split functionality up as company hierarchy often reflects that pretty clearly.

Note that the blog post speaks about modules, not classes. It is a bit more abstract and higher level. Note also that the reference to people is mostly to clarify what it means that a piece of software (module or - depending on your design - class) should have one concern/job. The post doesn't say only one person should edit the code or the like. It just says that change to one class should originate from one source and if you go high enough in a company theoretically you can trace that to one person. However, this all just serves to make "one job" more clear - as on an organizational level it is easier to understand that say the department for public relations should make no decision that directly requires a change in the method calculates money each employee gets each month. They might use the output of said method when trying to hire people but should not change it. If you go out into the real world of company organisation that sometimes makes it clearer what domain an operation belongs to and how to split functionality up.

Note that the blog post speaks about modules, not classes. It is a bit more abstract and higher level. Note also that the reference to people is mostly to clarify what it means that a piece of software (module or - depending on your design - class) should have one concern/job. The post doesn't say only one person should edit the code or the like. It just says that change to one class should originate from one source and if you go high enough in a company theoretically you can trace that to one person. However, this all just serves to make "one job" more clear - as on an organizational level it is easier to understand that say the department for public relations should make no decision that directly requires a change in the method that calculates money each employee gets each month. They might use the output of said method when trying to hire people but should not change it. If you go out into the real world of company organisation that sometimes makes it clearer what domain an operation belongs to and how to split functionality up.