[deleted]
Famous Laws of Software Development (2017)
51–60 of 202 posts
Re: Famous Laws of Software Development (2017)
#52I feel like Fonzie's Law would be a worthwhile inclusion: "The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
Re: Famous Laws of Software Development (2017)
#53Regarding Conway's Law: We have found that by changing our software/system architecture we have also inadvertently changed our organisation structure. - Inverse Conway Law or just Roy's Law ;-) Before we had four cross functional teams, working on a single application, everyone felt responsible for it, worked overtime to fix bugs etc, we had good communication between the teams. But after we switched to microservices…
> They stopped talking to each other because they didn't share any code, no issues... they stopped having lunch together, some things got way worse in the organisation, all sparked by a 'simple' architectural change, moving to microservices.
Honestly, this sounds like an improvement.
Re: Famous Laws of Software Development (2017)
#54Regarding Conway's Law: We have found that by changing our software/system architecture we have also inadvertently changed our organisation structure. - Inverse Conway Law or just Roy's Law ;-) Before we had four cross functional teams, working on a single application, everyone felt responsible for it, worked overtime to fix bugs etc, we had good communication between the teams. But after we switched to microservices…
> They stopped talking to each other because they didn't share any code, no issues... they stopped having lunch together, some things got way worse in the organisation, all sparked by a 'simple' architectural change, moving to microservices. Honestly, this sounds like an improvement.
How is people not talking to each other an improvement?
Re: Famous Laws of Software Development (2017)
#55Missing: Goodhearts Law
Re: Famous Laws of Software Development (2017)
#56Regarding Conway's Law: We have found that by changing our software/system architecture we have also inadvertently changed our organisation structure. - Inverse Conway Law or just Roy's Law ;-) Before we had four cross functional teams, working on a single application, everyone felt responsible for it, worked overtime to fix bugs etc, we had good communication between the teams. But after we switched to microservices…
I have seen new systems/software implemented just to isolate/remove parts of an organization. Worse I have seen it done when the existing system/software was just fine.
Re: Famous Laws of Software Development (2017)
#57Quick and dirty is rarely quick and always dirty.
(Don't know if it has a name)
Re: Famous Laws of Software Development (2017)
#58Regarding Conway's Law: We have found that by changing our software/system architecture we have also inadvertently changed our organisation structure. - Inverse Conway Law or just Roy's Law ;-) Before we had four cross functional teams, working on a single application, everyone felt responsible for it, worked overtime to fix bugs etc, we had good communication between the teams. But after we switched to microservices…
> “Before we had four cross functional teams, working on a single application, everyone felt responsible for it, worked overtime to fix bugs etc, we had good communication between the teams.”
This actually sounds very dysfunctional, but with the type of positive PR spin that product / executive management wants, basically anyone who believes “cross-functional” is anything more than a buzzword.
Would love to know what the engineers thought about working in that environment (which sounds like a monolithic, too-many-cooks, zero specialization situation likely negatively affecting career growth & routine skill building).
Re: Famous Laws of Software Development (2017)
#59Regarding Conway's Law: We have found that by changing our software/system architecture we have also inadvertently changed our organisation structure. - Inverse Conway Law or just Roy's Law ;-) Before we had four cross functional teams, working on a single application, everyone felt responsible for it, worked overtime to fix bugs etc, we had good communication between the teams. But after we switched to microservices…
> They stopped talking to each other because they didn't share any code, no issues... they stopped having lunch together
Was that accompanied by any growth in company size? I've found that this happens when a group grows past about 15 people even if the structure doesn't change.
Re: Famous Laws of Software Development (2017)
#60Hyrum's law is highly relevant to anyone who makes software libraries. "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." I.e. any internal implementation details that leak as behavior of the API become part of the API. Cf. Microsoft's famous "bug for bug" API compatibility through versions of Win…
They might become part of the API in a superficial sense, but if you broadcast clearly that undocumented behaviors are subject to change, then users can decide if they want to accept that risk and won’t have a valid complaint if they want the not-covered-by-the-contractual-API preserved or become surprised by a change.