Reading Extreme Programming Refactored: The Case Against XP post

Reading http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp

Disclaimer: I don't think I know enough about XP and Agile to call myself a expert. I havent read enough books on the subject.

But I have worked in companies where we tried XP and tried to be Agile and tried to use Scrum.

I think you need the know the Pros and Cons of a methodology or method so lets see what this article is saying about XP.


"However, they refused to allow the team to perform any refactoring on the morass of badly formed code that emerged, because they felt that now the code was written, spending more time on it would be a waste of money.

The programmers also finished-off each code module too quickly because they hated to pair program. The result was a monolithic city of heavily interwoven code with huge amounts of duplication, coupled with unit tests that took literally hours to run and left the database in an "unclean" state (i.e. needed to be picked apart manually after running the tests)."

I have seen a project before that also had the issue where the project wasn't re-factored on a regular basis and the code was very intertwined and the tests did take hours.....so could this be because of trying out XP on this project or is this just a observation that could be applied to all bad projects?

"Constant refactoring could potentially introduce lots of bugs, as dependent code is broken when you make small insidious changes to your design; but it's considered safe because of extensive unit testing."


Experienced this as well because some of the code that was done by a team under pressure didn't have enough tests and the refactoring broke a lot of functionality? Could this also be a problem related to not merging enough? Not enough code reviews? Not enough communication between teams?

"Because XP as a process does not involve getting a design spec reviewed by senior engineers, and instead places the emphasis on a constantly evolving design, this can be a high risk. "
I agree.

http://www.softwarereality.com/lifecycle/xp/xp_audience.jsp

"XP is aimed at customers who don't know what they want."
Is this really true?

My experience is that there is a business case document stating at a high level what they want. Then maybe a document with a few user stories or scenarios. Plus then the question becomes of what can we deliver maybe in 2 or 4 weeks for example. Can we deliver small bits that they can use and test?
Is this Agile?

The other thing I have seen is that the deadline has been set without grooming and planning sessions. Sometimes without even senior developers input........and I have never seen us deliver on that deadlines as it was never realistic to start with.

"There are processes that are much better suited to handling change halfway through a project - providing requirements traceability and impact analysis "
Like?

"(including support for quickly providing cost estimates so that the customer can make an informed decision about whether to authorise any changes)."
This is the one thing I haven't seen in our projects. Adjusting costs when change happens........

"For example, the customer might simply be unsure about exactly what their business requires. This is where you come in, as a business consultant: you should be presenting the customer with use cases, mock screenshots, prototypes (using quickly knocked-together, throwaway code). This all helps the customer to visualise what they really want, helping them to pin down the requirements before a single line of production code is written."

RAD?

"all the really hard thinking would have been done up front, and all the hard questions would have been asked (and answered). The problem domains have been identified; the nastiest problems carefully thought through and resolved."

I though that the we keep missing the real problems and only when we start coding do we find them and that is why XP and Agile wants to start coding quickly and show the client their understanding at the moment so that the client can also see if this is really what he meant and also find the real hidden technical difficulties early rather than later?

" In other words, the developers get very excited about an idea they (or the in-house customer) have had, and in chatting about it they become even more excited. In it goes. But the real customer (that reticent, cigar-chewing man back at Customer Towers) might not be quite so appreciative of this shiny new feature."

Mmm this is also true..........I have seen teams working very hard creating code and having a client that keeps them busy but did they achieve what the "board" or the big boss wanted overall? Could the client representative also have lost his view during the projects and have gone off in a tangent? Did we have a person that upfront challenged the client to clearly think about what he/she wanted?

Stupid question...........so you create stories, you add them to for example Jira. Devs go and do the work and write the tests. Is there an overall view of all the Stories to explain the functionality in the application that you can give to a CEO?

I sometimes feel there is a massive list of tasks over 6 months and then how many off them was removed in later sprints for example when the client realised that a story is incorrect or irrelevant? How do you extract the final stories that have been implemented in your application? I am sure the experts can give me the answer :)

http://www.softwarereality.com/lifecycle/xp/four_values.jsp

" And so, through countless waves of throwaway code, the design gradually (hopefully) starts to evolve. To counter this time-consuming, high risk approach, we are encouraged to keep everything simple."

What is simple? I have seen teams almost go into a constant cycle of refactoring to find the perfect solution to get to the perfect OO design. Isn't this costing money? Is the team still moving forward? Is this still simple? What is simple? What is perfect? When will we stop?

One of my friends send me this link which is very interesting on the topic of Easy and Simple......I don't agree with everything and it is so easy to misunderstand this presentation (there I go being vague and not providing proof...) but still it makes you think:

http://www.infoq.com/presentations/Simple-Made-Easy by Rich Hickey

" A common example is to produce a "framework" due to some unknown, hypothetical future requirement. If the requirement isn't there now, don't code for it."

Agree. Plus why write a framework? Can you write a better persistence framework? Or web framework and should you be doing it at your clients expense? Ok going off topic.....
"The result (as described above) is that in XP you end up writing code which you know is going to be rewritten later."

Is this really true? Aren't wegoing to expand on the code of yesterday? I don't think we are going to rewrite it.

"The difference with XP is that customer negotiation is arranged so that it runs throughout the project, and is fundamental to the way the process works at every stage. Due to the nature of XP's contracts, contract negotiation effectively takes place every time a programmer talks to the on-site customer.
I would suggest that your programmers are probably not the best people to handle the finer points of customer negotiations"

I agree

"Then the actual problem hit me. It's actually a general problem with XP, and its "throwaway" approach to production code. The programmers are encouraged to write with an attitude of "I'll just start coding and see what happens." If they end up writing garbage, it doesn't matter because they can just throw it away, go home clean, and start again tomorrow. Same goes for the design. Let it evolve, and see where it goes. The collective consciousness of the XP team will nudge the so-called design to some place or other. When it's there, if it's wrong then we'll just collectively nudge it somewhere else."

Isn't this where senior devs will come into play? Or shouldn't it become clear in daily stand-ups that we are not moving forward and that something is wrong? But again this creates an effect that teams are busy but they could be rewriting the system everyday to get to that "perfect code" but then the Simple value should kick in here and stop the developer?

"You just need to be good at what you do, as with any skilled vocation. You need some aptitude and imagination. You don't have to create something to know whether it is going to work or not. Just think ahead, factor in as much as you can without losing sight of your goal."

I agree with the thinking ahead part and that skill and experience is needed.

"Despite its flaws, XP's practices can also be tweaked to make the overall process more robust. Don't get too caught up in blind adherence to one methodology. Try not to end up chasing your own tail in order to be agile. Software agility is useful, but it's simply a means to an end."

I agree. Learn different methodologies but  don't follow them blindly and be aware of the pitfalls of any method or methodology.

"Apply whatever practices that work for your project. Read the Steve McConnell books cover to cover (he's got it right, including the Evolutionary Delivery stuff). Use what's right for you."
I agree even more with this statement :)

"RUP" I also like to try this again..........plus I think RUP has adapted in the last few years. Anyone with experience of using RUP?


""Extreme Programming Refactored

In this book (co-authored with Doug Rosenberg), we suggest some modifications to the XP practices (plus some additional practices) to achieve XP's agile goals in a more rigorous and less risk-laden way."
Would be interesting to see the modifications........

Overall I wonder how this article would change after reading Kent Beck's second version of his book?