Confusion with XP

[tankh99]

How does XP programming enable developers to quickly provide solutions immediately rather than later if the basis of XP is to prioritise refactoring?

[damithc]

How does XP programming enable developers to quickly provide solutions immediately rather than later if the basis of XP is to prioritise refactoring?

@tankh99 Where did you find these two assertions about XP?

[tankh99]

How does XP programming enable developers to quickly provide solutions immediately rather than later if the basis of XP is to prioritise refactoring?

@tankh99 Where did you find these two assertions about XP?

The prior 2 assertions were assumptions made based on some things that the textbook mentioned. Also, my use of "immediately" is probably incorrect, I meant to say "provide solutions sooner rather than later".

For the 1st assertion about providing solutions sooner. I interpreted "delivering the software as you need it" as being able to provide solutions quickly. Though, I'm not exactly sure what "far into the future" is trying to compare against. Is it comparing itself against SCRUM?

For the 2nd assertion about prioritising refactoring, "They keep their design simple and clean" from below, and online searching which brought up things like "continuously improving code", which is to refactor

[tankh99]

@damithc Bump on this.

[damithc]

One can argue that to be able to deliver features quickly (and frequently -- software project are long term, and need to deliver features many times, over long periods), the code quality needs to be good (i.e., 'quick' doesn't mean 'quick and dirty'). Otherwise, adding/changing features become progressively harder as the code becomes progressively messier.

So, XP tries to achieve a balance of both. i.e., keep the code clean by continuous refactoring so that you can evolve the product at a high rate without making the code messy.

[tankh99]

Noted, thank you @damithc !