CI Feedback & Metrics - Revision history

Macetw at 14:25, 27 August 2013

2013-08-27T14:25:28Z

Macetw: Added tool note: Coverty.

2013-08-24T23:34:47Z

Added tool note: Coverty.

Macetw: /* How do you measure? */

2013-08-24T19:08:27Z

How do you measure?

Macetw at 18:45, 24 August 2013

2013-08-24T18:45:51Z

Macetw at 18:28, 24 August 2013

2013-08-24T18:28:02Z

Macetw: /* How do you measure? */

2013-08-24T18:21:48Z

How do you measure?

Macetw: Created page with " ==How do you measure?== On the product side, we can log when people are using features * on small scale, can interact with (call) the customer What percentage of builds fa..."

2013-08-24T18:13:26Z

Created page with " ==How do you measure?== On the product side, we can log when people are using features * on small scale, can interact with (call) the customer What percentage of builds fa..."

New page

==How do you measure?==
On the product side, we can log when people are using features
* on small scale, can interact with (call) the customer

What percentage of builds fail?
Tradeoff of build failures, vs frequency of builds ?

Continuous deployment, measuring $/unit of work, can we measure customer-revenue outcomes from how we are committing our code?

@@ Line 51: / Line 51: @@
 * Code compiler warnings
 ** e.g. codenarc
-** '''EDIT''' ''by macetw'' The tool I was trying to think of is Coverty, which monitors NEW warnings, distinct from Existing warnings. Coverty is a non-free product.
+** '''EDIT''' ''by macetw'' The tool I was trying to think of is [www.coverity.com Coverty,] which monitors NEW warnings, distinct from Existing warnings. Coverty is a non-free product.
 ** Build failing if new warnings, or any warnings
 ** e.g. copy/paste detection

@@ Line 51: / Line 51: @@
 * Code compiler warnings
 ** e.g. codenarc
 ** Build failing if new warnings, or any warnings
 ** e.g. copy/paste detection
 * Organizational dysfunction, of when team members are not pulling their weight in quality
 ** How do we give visibility to management or to the team
 What are the metrics for risk?

← Older revision		Revision as of 19:08, 24 August 2013
Line 43:		Line 43:
	** Maybe we could do that per 15 minutes		** Maybe we could do that per 15 minutes
	*** Every 15 minutes, a timer goes off. After that time, we have a discussion. Should we commit? If not, should we revert? If not, make sure it's ready after another 15 minutes.		*** Every 15 minutes, a timer goes off. After that time, we have a discussion. Should we commit? If not, should we revert? If not, make sure it's ready after another 15 minutes.
		+
		+	See also:
		+	[http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783 Lean Software Development]
		+
		+	What metrics?
		+	* Static analysis warnings
		+	* Code compiler warnings
		+	** e.g. codenarc
		+	** Build failing if new warnings, or any warnings
		+	** e.g. copy/paste detection
		+	* Organizational dysfunction, of when team members are not pulling their weight in quality
		+	** How do we give visibility to management or to the team
		+
		+	What are the metrics for risk?
		+	* Metrics for risk are consistent within a project, but not across projects
		+	** Cyclomatic complexity may be high for a certain project
		+
		+	See also:
		+	* @JTF: ??
		+
		+	Associate defects across releases
		+	* fingerprint defects to releases.
		+
		+	Principals of product development flow reinertsen
		+	* The larger the batch-size, the more expensive it is. Smaller batches, cheaper.
		+	* See also:
		+	** [http://www.amazon.com/The-Principles-Product-Development-Flow/dp/1935401009 Principals of product development flow]
		+
		+	"every time you run an assertion, you have a chance to learn something"
		+
		+	*Metrics should ask questions, not give answers
		+	*Individuals should want it - it's not really for managers
		+	*Developers have had discussions about results, make plans accordingly
		+
		+	Tool idea:
		+	* Developer Karma plugin for Jenkins
		+	* Tool to identify "most failing" tests
		+
		+	%50 of Flickering tests identify code defects.
		+
		+	Participants
		+	* Scribe: @macetw
		+	* @Jtf
		+	* Emil
		+	* @EricMinick
		+	* Others (volunteers)

@@ Line 21: / Line 21: @@
 * Sonar
-Using debt in coding
+*Using debt in coding
-* is it okay for taking on debt
+** is it okay for taking on debt
 ** Even if it is for meeting deadlines?
 * code review process makes a process
@@ Line 29: / Line 29: @@
 ** With span of data over several decades
 * Different people work differently, Members of teams don't always approach problems of finishing tasks, in a way that is quality.

← Older revision		Revision as of 18:28, 24 August 2013
Line 20:		Line 20:
	** Cyclomatic complexity vs. code coverage		** Cyclomatic complexity vs. code coverage
	* Sonar		* Sonar
		+
		+	Using debt in coding
		+	* is it okay for taking on debt
		+	** Even if it is for meeting deadlines?
		+	* code review process makes a process
		+	* @JTF: positive correlation between speed and quality
		+	** That certain teams that put out features faster also put out in high quality.
		+	** With span of data over several decades
		+	* Different people work differently, Members of teams don't always approach problems of finishing tasks, in a way that is quality.

← Older revision		Revision as of 18:21, 24 August 2013
Line 11:		Line 11:

	Continuous deployment, measuring $/unit of work, can we measure customer-revenue outcomes from how we are committing our code?		Continuous deployment, measuring $/unit of work, can we measure customer-revenue outcomes from how we are committing our code?
		+
		+	defect rate, commit/build rate, what is the time to detect rate?
		+	* Granular feedback may or may not have as much value, compared to hardware costs and time-to-detection feedback
		+	** Any builds longer than 10 seconds are not okay
		+
		+	Feedback of code
		+	* Crap for J
		+	** Cyclomatic complexity vs. code coverage
		+	* Sonar