Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Extreme Programming, a Reflection

blog.8thlight.com

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Extreme Programming, a Reflection

#21

Post by henrik_w »

crdoconnor wrote: post #12
barrkel wrote: post #7

The 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 sho…

>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. I think this highlights a deficiency in testing tools. It's quite hard to, for example, change the system time when running a test which often means that you have to abstract out that part from the method you're testing and pass it…

The question of time in relation to tests is interesting. If you write the code with the mindset that you should be able to test it (including time dependent behavior), you can end up with testable code without too much trouble. The key is to make time external to the code. I just blogged about this in "TDD, Unit Tests and the Passage of Time" http://henrikwarne.com/2013/12/08/tdd-unit-tests-and-the-pas...

Re: Extreme Programming, a Reflection

#22

Post by pjmlp »

kabouseng wrote: post #18
pjmlp wrote: post #14

Earlier quoted context omitted.

> Test-first TDD is even less popular I never bought into TDD, although I do write unit tests for most of the code where it makes sense. No one has been able to show me an usable way to do TDD when coding native UIs, mobile OS, embedded systems or when using third party libraries not built with testing in mind. Plus TDD makes very hard to properly design algorithms and data structures, that should beforehand be done…

Have a look at test driven development for embedded C by James Grenning for a viewpoint of how TDD might work in the embedded world. I found it to be a great resource. http://pragprog.com/book/jgade/test-driven-development-for-e...

Thanks, I know that book.

Re: Extreme Programming, a Reflection

#23

Post by heleph »

barrkel wrote: post #7

The 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 sho…

Pair programming is supposed to be two people thinking through the problem together. It works when both people are immersed in solving the problem together.

When it works well, having two brains working together brings the benefit of different perspective and experience. It gives the opportunity to riff off each other's ideas. You spot issues with design and implementation earlier because having to communicate your ideas means working harder on them before you try to turn them into code.

I find it fun to work with someone else who is smart and engaged. It's magic when you become warmed up enough that things really start to flow. I've actually managed to get into flow before while working with someone else.

That said, it's pretty difficult to get right. I found it quite hard to let someone else see my process. If both sides aren't engaged in problem solving it can be really boring. I've also found that it takes me a while to figure out how to work productively with new people. The dynamic between any particular pair of people is a bit different. I think you need to build trust with your pair.

Re: Extreme Programming, a Reflection

#24

Post by henrik_w »

heleph wrote: post #23
barrkel wrote: post #7

The 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 sho…

Pair programming is supposed to be two people thinking through the problem together. It works when both people are immersed in solving the problem together. When it works well, having two brains working together brings the benefit of different perspective and experience. It gives the opportunity to riff off each other's ideas. You spot issues with design and implementation earlier because having to communicate your i…

A "simpler" version is discussing the problem with your colleague in front of a whiteboard (drawing almost always seems to help). Once you've worked out how to implement it, you go off and implement it yourself.

Re: Extreme Programming, a Reflection

#25

Post by barrkel »

henrik_w wrote: post #11
barrkel wrote: post #7

The 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 sho…

I don't agree with "making code easy to test tends to over-abstract it". The dependencies are there no matter what, but they become more obvious when you try to test the code in isolation. I think the main benefit of TDD is the way it forces you to break the program apart in smaller, less dependent pieces. The end result is better structure and less dependencies between parts.

I fundamentally disagree with you.

If the goal in writing software is to reduce it to a set of pieces that plug together, I'd agree. But it's an arbitrary metric and not an absolute measure of quality, not by a long shot.

Note that I don't say "composable", because composability is something that needs to be designed in, and it isn't usually clear how to do it best until the third or so time around - the rule of threes.

Furthermore, I don't say reusable, because reusability is something that also needs to be designed for. In particular, reusability in such a way that software can evolve over time without breaking clients (reusers) of the abstraction demands a tight and constrained contract that is broadened carefully, while testable components demand broad and flexible contracts, otherwise not everything would be available to be tested.

Every part that testing has forced you to break out to be individually addressable is a part that you cannot remove in a refactoring that significantly changes the way a library solves its problem.

A library that has been broken into parts that are neither composable nor reusable is simply over-complex. Almost every extant Java library is like this!

Of course, if you just write end software in small teams, none of this is relevant to you. But it is crucial in library design, especially when client code is outside of your organization.

Re: Extreme Programming, a Reflection

#26

Post by discreteevent »

ollysb wrote: post #4
henrik_w wrote: post #2

The 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…

The main thing for me is that its virtually impossible to build a complex system (essentially complex that is) without having good feedback and then adjusting the design to fit. That feedback comes from testing, review and the customer. The shorter the feedback cycle the quicker you settle on the target. The XP book helped spur this on in an age where a lot of people had lost the run of themselves. However these ideas were around and practiced since software development started:

http://www.craiglarman.com/wiki/downloads/misc/history-of-it...

And before that for other activities: "Plans are nothing; planning is everything." - Dwight D. Eisenhower

Re: Extreme Programming, a Reflection

#27

Post by thebear »

In the short section entitled "Success" toward the end of the article, the author repeats the sentence "Extreme Programming succeeded" five times, slightly rephrased each time. To be perfectly honest, I find it hard to comment on this without sounding derisive. There is no hint at what "succeeding" even means for a software methodology, and even if we assume we know what "succeeding" means in this context, there is not a shred of evidence for the truth of the statement. A poorly defined statement repeated five times without evidence or proof.

Re: Extreme Programming, a Reflection

#28

Post by henrik_w »

barrkel wrote: post #25
henrik_w wrote: post #11

Earlier quoted context omitted.

I don't agree with "making code easy to test tends to over-abstract it". The dependencies are there no matter what, but they become more obvious when you try to test the code in isolation. I think the main benefit of TDD is the way it forces you to break the program apart in smaller, less dependent pieces. The end result is better structure and less dependencies between parts.

I fundamentally disagree with you. If the goal in writing software is to reduce it to a set of pieces that plug together, I'd agree. But it's an arbitrary metric and not an absolute measure of quality, not by a long shot. Note that I don't say "composable", because composability is something that needs to be designed in, and it isn't usually clear how to do it best until the third or so time around - the rule of thre…

A program made up of loosely coupled pieces has several advantages over one that is more monolithic. It is composable – all you have to do is put the parts together, then you have your complete program. It is easier to modify, because parts can be swapped out with minimal impact. It is easier to test, since the parts can be tested in isolation, which makes testing the complete program much easier.

As for reuse, I like this quote: "Don't aim for reuse. Write small, independent components you can reason about, and the right pieces for reuse will fall out." Jessica Kerr @jessitron on Twitter

Re: Extreme Programming, a Reflection

#29

Post by berntb »

lmm wrote: post #20
pistacchioso wrote: post #3

Putting 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.

I don't enjoy pair-programming. I avoid it as much as I can get away with. But looking at the results, it's an inescapable fact that I produce higher-quality code when I do - so for those critical pieces that need to be bug-free, I force myself to do it.

Is that personal experience or a general research result?

Is the result better than with careful code reviews [of the critical pieces] (both after writing, but also short checks during development over a code listing and coffee)?

Intuitively, everything with coffee involved ought to be better! :-)

Re: Extreme Programming, a Reflection

#30

Post by lmm »

berntb wrote: post #29
lmm wrote: post #20

Earlier quoted context omitted.

I don't enjoy pair-programming. I avoid it as much as I can get away with. But looking at the results, it's an inescapable fact that I produce higher-quality code when I do - so for those critical pieces that need to be bug-free, I force myself to do it.

Is that personal experience or a general research result? Is the result better than with careful code reviews [of the critical pieces] (both after writing, but also short checks during development over a code listing and coffee)? Intuitively, everything with coffee involved ought to be better! :-)

Just personal experience.

Better than some theoretically perfect practice of careful code reviews? I don't know. Better than code reviews as actually implemented everywhere I've worked? Yes. (In particular I find it's really hard to maintain the discipline of carefully going through each other's code when you know that most of the time you won't find anything)

Post reply on HN