gistya · August 29, 2015 14:19
diff --git a/efficiency.txt b/efficiency.txt
 Theorem.

 Reed could improve the efficiency of its methods of updating its policies like DHSM, and could thereby improve the effectiveness of those policies, by adopting some tools and methods commonly used to manage cross-team software development inside companies like Apple, Google, Microsoft, and Nike. The tools and methods I speak of were made for collaboratively developing code, which could include community policies. 

 Explanation.

 Before we deploy a major software update to a live server, we run it through copious codified test suites, then deploy to a mock server and have QA monkeys try as hard as possible to break it. When we finally deploy to a live server, we monitor it closely for problems, with one finger on the "roll-back" button, the rest of the fingers ready to whip up an emergency hotfix. Murphy's Law dictates that major updates will always have unforeseen issues, because they can. Some subset of users inevitably hates the new features that you added in response to a flood of complaints from a different subset of users—and that's a good day. 

 We absolutely depend upon comprehensive issue-reporting and tracking systems like Github to isolate discussions about particular aspects of problems to the lines of code that they pertain to. That way the rationale behind changes is visible to all participants in the project, but only if they care to look at the arguments behind a particular aspect of a change. It also lets us deploy small, non-controversial changes in an ad-hoc fashion, kind of like a "line item veto" but way more flexible. In-person meetings become far more productive and issue-focused when they do happen, because as long as people "do the reading" beforehand then teams don't need to explain the rationale behind every little thing or answer objections that have already been hashed out in the threads specific to each proposed change. The "agile" methodology lets us quickly deploy need-driven changes after "sprints" of development.

 Examples. 

 I'm not the first to suggest using git and other tools and methods to enhance policymaking. Some dude keeps the entirety of German Federal Law at bundestag.github.com/gesetze. And gitlaw.us has links to discussions about using git for lawmaking. 

 But I'm not aware of any institutions actually USING github to work on policy. Wouldn't it be cool if Reed was first? :D

 Axiom.

 The efficiency of institutional methodologies for developing policies can be optimized.

 The effectiveness of policies can optimized.

 Engineering is the best approach for optimizing systems through prototyping, testing, measurements, parameters, and refinement.

 Reed has almost zero engineers.

 Software is policy.

 Software engineering is policy engineering.

 Companies have policies.

 Software companies employ software engineers. 

 Proof.

 1) Given the set X of all institutional processes and methodologies used for developing, approving, and deploying major, necessary policy updates like DHSM. E.g. committees, meetings, drafting, revision, etc.

 2) There must exist alternate set Y that is more efficient.

 3) Consider that Reed's primary function is to teach students, not self-diagnose the level of efficiency of its methodologies for developing and implementing code changes.

 4) Consider that the software development industry, HAS self-diagnosed the level of efficiency of its methodologies for developing and implementing code changes via cross-team collaboration, AND engineered tools specifically designed to increase said efficiency. 

 5) Consider that since the content of the code is only indirectly relevant to the efficiency of the process used to change it, the methodologies and tools that help software engineers can also help Reed's policymakers. 

 6) Consider that reducing inefficiency speeds compliance with best practice and mitigates risk, justifying any financial cost involved with implementing changes necessary to enhance the efficiency of Reed's policymaking.

 7) See theorem.

 Discussion.

 Think about the benefit of a system that could automatically organize communication about proposed changes into searchable threads specific to any proposed change or set of changes, would forever remain embedded in the living history of the final document, and would be subject to moderation by team members put in charge over specific subsets of the code as well as admins.

 Decluttering and organizing comment threads exponentially decreases the time required to understand the rationale for any given specific change. Especially when it's all searchable and organized. 

 Greasing a one squeaky wheel is far less likely to degrease any quiet wheels if the quiet wheels can go online and read the comment threads of each change and THEN, if they have any concern that was not already hashed out, ask much more intelligent questions, having "done the reading."

 Facebook threads and committee meetings alone are a terribly inefficient approach to the collaborative development of code (be it DHSM policy or an iPhone app).

 Author.

 Jon Gilbert '03
	Theorem.

	Reed could improve the efficiency of its methods of updating its policies like DHSM, and could thereby improve the effectiveness of those policies, by adopting some tools and methods commonly used to manage cross-team software development inside companies like Apple, Google, Microsoft, and Nike. The tools and methods I speak of were made for collaboratively developing code, which could include community policies.

	Explanation.

	Before we deploy a major software update to a live server, we run it through copious codified test suites, then deploy to a mock server and have QA monkeys try as hard as possible to break it. When we finally deploy to a live server, we monitor it closely for problems, with one finger on the "roll-back" button, the rest of the fingers ready to whip up an emergency hotfix. Murphy's Law dictates that major updates will always have unforeseen issues, because they can. Some subset of users inevitably hates the new features that you added in response to a flood of complaints from a different subset of users—and that's a good day.

	We absolutely depend upon comprehensive issue-reporting and tracking systems like Github to isolate discussions about particular aspects of problems to the lines of code that they pertain to. That way the rationale behind changes is visible to all participants in the project, but only if they care to look at the arguments behind a particular aspect of a change. It also lets us deploy small, non-controversial changes in an ad-hoc fashion, kind of like a "line item veto" but way more flexible. In-person meetings become far more productive and issue-focused when they do happen, because as long as people "do the reading" beforehand then teams don't need to explain the rationale behind every little thing or answer objections that have already been hashed out in the threads specific to each proposed change. The "agile" methodology lets us quickly deploy need-driven changes after "sprints" of development.

	Examples.

	I'm not the first to suggest using git and other tools and methods to enhance policymaking. Some dude keeps the entirety of German Federal Law at bundestag.github.com/gesetze. And gitlaw.us has links to discussions about using git for lawmaking.

	But I'm not aware of any institutions actually USING github to work on policy. Wouldn't it be cool if Reed was first? :D

	Axiom.

	The efficiency of institutional methodologies for developing policies can be optimized.

	The effectiveness of policies can optimized.

	Engineering is the best approach for optimizing systems through prototyping, testing, measurements, parameters, and refinement.

	Reed has almost zero engineers.

	Software is policy.

	Software engineering is policy engineering.

	Companies have policies.

	Software companies employ software engineers.

	Proof.

	1) Given the set X of all institutional processes and methodologies used for developing, approving, and deploying major, necessary policy updates like DHSM. E.g. committees, meetings, drafting, revision, etc.

	2) There must exist alternate set Y that is more efficient.

	3) Consider that Reed's primary function is to teach students, not self-diagnose the level of efficiency of its methodologies for developing and implementing code changes.

	4) Consider that the software development industry, HAS self-diagnosed the level of efficiency of its methodologies for developing and implementing code changes via cross-team collaboration, AND engineered tools specifically designed to increase said efficiency.

	5) Consider that since the content of the code is only indirectly relevant to the efficiency of the process used to change it, the methodologies and tools that help software engineers can also help Reed's policymakers.

	6) Consider that reducing inefficiency speeds compliance with best practice and mitigates risk, justifying any financial cost involved with implementing changes necessary to enhance the efficiency of Reed's policymaking.

	7) See theorem.

	Discussion.

	Think about the benefit of a system that could automatically organize communication about proposed changes into searchable threads specific to any proposed change or set of changes, would forever remain embedded in the living history of the final document, and would be subject to moderation by team members put in charge over specific subsets of the code as well as admins.

	Decluttering and organizing comment threads exponentially decreases the time required to understand the rationale for any given specific change. Especially when it's all searchable and organized.

	Greasing a one squeaky wheel is far less likely to degrease any quiet wheels if the quiet wheels can go online and read the comment threads of each change and THEN, if they have any concern that was not already hashed out, ask much more intelligent questions, having "done the reading."

	Facebook threads and committee meetings alone are a terribly inefficient approach to the collaborative development of code (be it DHSM policy or an iPhone app).

	Author.

	Jon Gilbert '03
No results found