Clarifying the intended and unintended consequences of SCER

[jawache]

As we develop standards it's important that we explore not just the intended consequences but also the unintended consequences.

During the development of the SCI we discussed at length many of the unintended consequences of a software measurement metric. This resulted in many fundamental core additions, clarifications and lots of thought in how to define a standard in such a way that we minimize the unintended consequences.

The choice to not include market based instruments was a result of that focus (we wanted to trigger the actions that encourage more engineering effort, and if we allowed market based instruments (offsets) to be included the unintended consequent of that choice would have been to encourage the purchasing of offsets instead of the investment into green engineering). The addition to add a disclosure of your software boundary was a result of a discussion around how an unintended consequence of the spec might be to redraw the boundary of your software in order to demonstrate reductions.

As we develop the SCER I believe it's good to be more formal regarding identifying, discussing and adjusting the spec to minimize unintended consequences.

I'm using this ticket as a top level ticket to define the sub tickets were we will capture these discussions.

Intended Consequences

• IC: Investment into green software engineering
• IC: Encourage transparency

Unintended Consequences

• UC: Software Boundary Redefinition #62
• UC: Functional Unit Redefinition #63
• UC: Manipulative Benchmark Optimization #64
• UC: Category Optimization #65
• UC: Use of Offsets over Efficiency #66
• UC: Discourage Transparency #67