Extreme Programming, a Reflection
blog.8thlight.com
Extreme Programming, a Reflection
1–10 of 69 posts
Re: Extreme Programming, a Reflection
#2The XP book was hugely important for me. I read Kent Beck's article on Extreme Programming in IEEE Software in October 1999, and got the book as soon as it came out.
For the first time I saw a methodology that reflected how I actually liked to work. I hadn't done pair-programming then, but working in small increments, with lots of tests, rewriting etc - more agile in short. Previously, I wrote programs despite the methodology (like RUP, or company internal methodologies), but here was a system that actually helped. Truly revolutionary at the time.
Re: Extreme Programming, a Reflection
#3Putting my headphones in, drifting in my own, private world of code is to me one of the simple pleasures of life. Ok with short meetings and thight, small schedules and the like, but put someone watching at my screen while I'm coding and I can easily commit an homicide.
Re: Extreme Programming, a Reflection
#4The XP book was hugely important for me. I read Kent Beck's article on Extreme Programming in IEEE Software in October 1999, and got the book as soon as it came out. For the first time I saw a methodology that reflected how I actually liked to work. I hadn't done pair-programming then, but working in small increments, with lots of tests, rewriting etc - more agile in short. Previously, I wrote programs despite the me…
The strange thing is that this is how everyone begins to program you write a little code and get something working. Then you add a little more, reorganise things a little and keep going. It's a natural process that somehow gets trained out of us in CS courses. We're taught how to plan a whole system and them build it. Long running projects interacting with an infathomonable number of users put paid to that though. I think the thing extreme programming got most right is that software is about people. Telling the computer what to do is the easy bit. Figuring out what the users want them to do is the hard part.
Re: Extreme Programming, a Reflection
#5Another post saying nothing by uncle Bob. His ability to say nothing never ceases to amaze me -_-.
He's one of the good guys, that's for sure - but every time I read his blog I keep waiting for that something new and it never comes.
Re: Extreme Programming, a Reflection
#6It's still relevant - I doubt that 2% of teams do all 12 (mostly it's the pair programming) but it is without a doubt the seminal work on software in business of the last 15 years.
Re: Extreme Programming, a Reflection
#7The things that I remember XP being controversial for were pair programming and TDD - real TDD, where you write the tests first and let the tests drive the design. And those are the two things that I don't really see as having caught on.
I mean, pairing is a fine approach when training someone up on a codebase, but it tends to be much more effortful for the guy in the driving seat, while the guy looking over your shoulder is making small comments and doing researchy lookups. This makes it less than efficient when both people are at the same knowledge level. The extra eyes looking for bugs is debatable; the bugs are more thoroughly found with tests.
Test-first TDD is even less popular. Norvig vs Jeffries was enlightening - http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/ .
Software does have a much heavier focus on testing than it used to, to the point that in many projects, everything is implemented twice - all features have two representations, one in the form of the implementation, another in the form of tests, and often with the lines of test code outnumbering the implementation.
But other things have suffered IMHO; making code easy to test tends to over-abstract it, making it more parameterized and exposing more implementation details of high-level abstractions.
APIs are often uglier with a lot more exposed symbols to handle the parameterization, with various bits and bobs asking for interfaces that only have one concrete implementation that can only be created by a factory, and you have to learn the knack of actually instantiating the useful bits anew for each library. I've got Java squarely in mind, of course, and I'm convinced better language design can solve the problem with less harm to the software.
Re: Extreme Programming, a Reflection
#8The XP book was hugely important for me. I read Kent Beck's article on Extreme Programming in IEEE Software in October 1999, and got the book as soon as it came out. For the first time I saw a methodology that reflected how I actually liked to work. I hadn't done pair-programming then, but working in small increments, with lots of tests, rewriting etc - more agile in short. Previously, I wrote programs despite the me…
The strange thing is that this is how everyone begins to program you write a little code and get something working. Then you add a little more, reorganise things a little and keep going. It's a natural process that somehow gets trained out of us in CS courses. We're taught how to plan a whole system and them build it. Long running projects interacting with an infathomonable number of users put paid to that though. I…
Exactly. You grow software. I really like this quote (by John Gall):
"A complex system that works is invariably found to have evolved from a simple system that worked."
Re: Extreme Programming, a Reflection
#9It's still relevant - I doubt that 2% of teams do all 12 (mostly it's the pair programming) but it is without a doubt the seminal work on software in business of the last 15 years.
In the enterprise world I move on, it is mostly a checklist to say a project is agile.
Many companies are still run waterfall like, or without any kind of process.
When we bring in agile methodologies into the project, it starts slowly, but eventually everything is in place and everyone is doing it in an agile way (XP, SCRUM, whatever).
When the first project escalation arrives, or the deadlines are not possible to be achieved, the developers start slowly going back to the original way of working.
In the end you get mini-waterfall projects with a sprint duration, but the management puts agile on the project bullet points.
Re: Extreme Programming, a Reflection
#10It's still relevant - I doubt that 2% of teams do all 12 (mostly it's the pair programming) but it is without a doubt the seminal work on software in business of the last 15 years.
In the enterprise world I move on, it is mostly a checklist to say a project is agile. Many companies are still run waterfall like, or without any kind of process. When we bring in agile methodologies into the project, it starts slowly, but eventually everything is in place and everyone is doing it in an agile way (XP, SCRUM, whatever). When the first project escalation arrives, or the deadlines are not possible to b…
I know the feeling - and my view is a bit brutal - but it's down to tools and people.
For most enterprises automated build, test, deploy (ie CI/CD) is the one missing tool and one absolutely necessary tool to capture and keep benefits of agile - it's capital.
And also for most enterprises you could lose 1/3 of the IT staff without noticing.