Extreme Hacking

ExtremeHacking is the subset of ExtremeProgramming that is used in the absence of coworkers or customers.

(not: PrettyAdventuresomeProgramming nor AlmostExtremeProgramming)

The seven practices of ExtremeHacking are:

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

ExtremeProgrammingForOne 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. -- GodefroidChapelle

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

CreepingFeaturitis 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 CodingStandards 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>!]

Therefore, 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