EvanBurchard · February 26, 2010 05:33
diff --git a/evanburchard pivotal project b/evanburchard pivotal project
 This is a project for tracking myself. The things I should do, don't do, wish I did, etc.

 "Bugs" are things that I don't like that I aim to change. They can be given by anyone at "failin.gs" email, or submitted in person. (nailbiting and the like)

 "Chores" are things that I need to do that don't add business value directly. (unimportant meetings, cleaning the gutters)

 "Features" are things that do add business value, ie. things that I enjoy, improve my skills, and benefit my relationships with others.

 There are two complications to using this project management system for this that I can predict now:

 One is defining deprecated features. If a bug is not really fixed, the bug ticket will be reopened or a new one will be created. If a chore is not done, it will be easy to tell (ie. do the trash). If a feature is to be deprecated, it can be coded considered a "bug." "This feature takes too many resources to support" is a valid reason to no longer support it. Ideally, there would be a "deprecation" type story, but there isn't, so "bug" will have to do. It may or may not take effort to stop supporting a feature.

 The other problem is that so much of life is made of recurring tasks. One solution would be to force the pmp to conform to your life, meaning that a cron job would hit the tracker api, telling you to go to work or practice the oboe.

 The alternative is to keep features small. This ensures an iterative process, and has the additional benefit of ensuring that you have a purpose in your daily life. If it doesn't add business value, you should not do it. If you can't think of a good reason to go to work in a given week, do something else. Also, it gives insight into why you took particular actions when reviewing later.

 Play X on the oboe so that I can be first chair. Go to work this week so that I can get money. Go to a play to change how I think about life. Work out so that I can wear the too tight pants.

 Not everything can be logged. Feeding the cat, brushing your teeth, climbing each of the stairs in a staircase, and running away from a fire would technically be considered "chores," but this is not the part of the "application" that I am working on. Basically, many recurring tasks like these can be thought of as features that are supported by the underlying architecture of a normal, conscious, sane person.

 Sometimes the underlying system needs to be tweaked. This should be handled in steps also. A bug report of "Forgive everyone for everything the world for every way that they've ever wronged me or each other, so that I can regain hope" is way too big, and is focused on the underlying architecture.

 Basically. It's a non-starter because you don't have access to the underlying architecture. The approach of "programming to an interface" is better. So a reasonable feature might be "Call mom to understand how I relate to people better." It's doable, finite, and approaches the problem at the interface level. If it becomes a regular thing, then you are still supporting the feature (or it has integrated itself a level deeper into your architecture). Address the feature again as "call mom," or a bug "did not call mom," or as a deprecation (bug story with "stop calling mom").
	This is a project for tracking myself. The things I should do, don't do, wish I did, etc.

	"Bugs" are things that I don't like that I aim to change. They can be given by anyone at "failin.gs" email, or submitted in person. (nailbiting and the like)

	"Chores" are things that I need to do that don't add business value directly. (unimportant meetings, cleaning the gutters)

	"Features" are things that do add business value, ie. things that I enjoy, improve my skills, and benefit my relationships with others.

	There are two complications to using this project management system for this that I can predict now:

	One is defining deprecated features. If a bug is not really fixed, the bug ticket will be reopened or a new one will be created. If a chore is not done, it will be easy to tell (ie. do the trash). If a feature is to be deprecated, it can be coded considered a "bug." "This feature takes too many resources to support" is a valid reason to no longer support it. Ideally, there would be a "deprecation" type story, but there isn't, so "bug" will have to do. It may or may not take effort to stop supporting a feature.

	The other problem is that so much of life is made of recurring tasks. One solution would be to force the pmp to conform to your life, meaning that a cron job would hit the tracker api, telling you to go to work or practice the oboe.

	The alternative is to keep features small. This ensures an iterative process, and has the additional benefit of ensuring that you have a purpose in your daily life. If it doesn't add business value, you should not do it. If you can't think of a good reason to go to work in a given week, do something else. Also, it gives insight into why you took particular actions when reviewing later.

	Play X on the oboe so that I can be first chair. Go to work this week so that I can get money. Go to a play to change how I think about life. Work out so that I can wear the too tight pants.

	Not everything can be logged. Feeding the cat, brushing your teeth, climbing each of the stairs in a staircase, and running away from a fire would technically be considered "chores," but this is not the part of the "application" that I am working on. Basically, many recurring tasks like these can be thought of as features that are supported by the underlying architecture of a normal, conscious, sane person.

	Sometimes the underlying system needs to be tweaked. This should be handled in steps also. A bug report of "Forgive everyone for everything the world for every way that they've ever wronged me or each other, so that I can regain hope" is way too big, and is focused on the underlying architecture.

	Basically. It's a non-starter because you don't have access to the underlying architecture. The approach of "programming to an interface" is better. So a reasonable feature might be "Call mom to understand how I relate to people better." It's doable, finite, and approaches the problem at the interface level. If it becomes a regular thing, then you are still supporting the feature (or it has integrated itself a level deeper into your architecture). Address the feature again as "call mom," or a bug "did not call mom," or as a deprecation (bug story with "stop calling mom").