is the subset of ExtremeProgramming
that is used in the absence of coworkers or customers.
The seven practices of ExtremeHacking
Agreed, except for the label. Solo programming is not necessarily hacking, particularly when pursued with the disciplines listed above. -- DaveSmith
But that's what makes it ExtremeHacking. Part of the essence of hacking is an incremental approach, most hackers hold to at least some CodingStandard, and so on. -- AlastairBridgewater
assumes a profit model. ExtremeHacking
does not, except for the milder draw of a GiftEconomy
. We are approaching ObservationsOfProgrammersInTheWild
here. -- PhlIp
How is this different from ExtremeProgrammingForOne?
No customer. Or, rather, the programmer is the customer. This actually means that the programmer and the customer have a perfect understanding of each other's position and all scheduling issues. Thus, the PlanningGame
disappears, as do UserStories
and a CommitmentSchedule
I disagree. User stories are extremely valuable even when you are working alone. I keep a list of features that I think would be valuable to implement and to a certain extent that list is also a plan. I prioritise my work based on 'bang for the my buck'. -- hjm
Without PlanningGame and..., how can you ascertain you are following the good path ? I am always unconfident with my ability not to lose the main track.
If you aren't confident in your ability to see what should be done next, you won't be able to build anything anyway.
I assume you do build things. Then you already have a natural sense of what should be done next. See also WorkQueue
. -- SunirShah
I have found that actually going through a semi formal planning game (I sit at the table, write out some user stories for myself, estimate them for myself and put them in an order) helps clarify issues. This stops me getting sidetracked, imposes development discipline and suggests ways I might functionally test the stuff I am developing. It is especially important because I work on this stuff in my spare time and often lose the plot. -- TomAyerst
I meant I sometimes let me disturb by the creeping features syndrome. -- GodefroidChapelle
I don't see this as a problem, as the lack-of-a-customer has obviously suggested the features. -- AlastairBridgewater
is just one of many problems with working in a vacuum. It is easy to miss the simple solutions, for code to be less clear, to get sidetracked on some little issue, etc. RonJeffries
tells a brief story about this problem in ExtremeProgrammingInstalled
(the section is labelled A True Story
What about ExtremeHacking
that doesn't have some of these things because it it written by people all over the world via the Internet? CombiningOpenSourceAndXp
But what would you get rid of? This list is pretty minimalistic as it is.
Might I take the soapbox for a moment? You know, felluz, there are two types of programmers in the world: (1) The "inspired" and (2) the "uninspired". The "inspired" have a better and more complete "feel" for the design of the entire project that they are coding WHILE THEY'RE CODING. Though they CAN also design by sitting and thinking or while rolling ideas around at a meeting, the design really flows and falls together when their hands are on the keyboard. This may partially be due to their ability to think more in the abstract, finding it actually cumbersome to try to frame things in a spoken language, or perhaps they are more fluent in the computer language they're using than they are in their spoken language. The "uninspired" just absolutely cannot understand this, because they've never felt it. They've never felt what it's like to have their mind explode and reach out into all of the future corners of a software project while their fingers are doing 130 words a minute trying to keep up. Because of this, the "uninspired" have a hard time believing the "inspired" when they tell them that they can design it better while they're coding. It sounds like voodoo to them, but they need to get over it. This really happens, and you need to take it into account before you start trying to lock the "inspired" into your little box. Your business will be far better off if you let them think outside YOUR box.
Some discussion on the CodingStandard
page suggests that CodingStandard
s may not be as useful as they seem on the surface, or that they may be mostly superseded by lightweight OralCommunication?
. [The best ExtremeHacker?s are often observed talking to themselves, <lol>!]
unless your ExtremeHacking
project has an externally-imposed requirement for a CodingStandard
(as some OpenSource
projects have), just follow your own eye-pleasing habits, with this one admonition: Be Consistent!
See ExtremeProgrammingForOne PrettyAdventuresomeProgramming