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

11–20 of 69 posts

Re: Extreme Programming, a Reflection

#11

Post by henrik_w »

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.

Re: Extreme Programming, a Reflection

#12

Post by crdoconnor »

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 through as a parameter.

You shouldn't need to do that (in python you don't!).

Also, there is a lot of APIs out there with very real world effects and integrations that it is pretty cumbersome to build mock ups of. Most API providers also just don't.

Mocking what would happen, say, when a twitter oauth token expires, isn't as easy as it should be.

On the plus side, UI testing tools seem a lot better nowadays.

But yeah, there's a serious dearth in good testing tools and bad language design (cough Java) that ends up making code unreadable.

Re: Extreme Programming, a Reflection

#13

Post by henrik_w »

lifeisstillgood wrote: post #10
pjmlp wrote: post #9

Earlier quoted context omitted.

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.

As edw519 tweeted:

(Great Process + Average People) < (Average Process + Great People)

Re: Extreme Programming, a Reflection

#14

Post by pjmlp »

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…

> 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 at the whiteboard.

Re: Extreme Programming, a Reflection

#15

Post by sgt »

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…

Regarding pair programming, I also see it as paying the salaries for 2x developers, yet gaining very little from it. Productivity may be even less than from a single programmer, at least in my experience.

To elaborate, I've tried pair programming myself and it was completely inefficient when we tried it. I'm not going to dismiss it entirely though, perhaps we approached it the wrong way. Personally I just need a bit of space before I can start focusing in-depth about certain problems.

This is also why I like to be well-prepared before attending team design decisions, because coming up with good ideas "right there and then" is difficult for me.

Re: Extreme Programming, a Reflection

#16

Post by pjmlp »

lifeisstillgood wrote: post #10
pjmlp wrote: post #9

Earlier quoted context omitted.

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.

Fully agree. In the end what we get from those projects is waterfall with CI, which is still better than how things used to be on the old days.

Although, one has this feeling of playing Quixote all the time.

Re: Extreme Programming, a Reflection

#18

Post by kabouseng »

pjmlp wrote: post #14
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…

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

Re: Extreme Programming, a Reflection

#19

Post by cs02rm0 »

sgt wrote: post #15
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…

Regarding pair programming, I also see it as paying the salaries for 2x developers, yet gaining very little from it. Productivity may be even less than from a single programmer, at least in my experience. To elaborate, I've tried pair programming myself and it was completely inefficient when we tried it. I'm not going to dismiss it entirely though, perhaps we approached it the wrong way. Personally I just need a bit…

Regarding pair programming, I also see it as paying the salaries for 2x developers, yet gaining very little from it.

I think the trick is to use it when developers feel necessary to stay productive. No point having someone slogging away at something they find difficult and frustrating if a second pair of eyes and maybe some more specific knowledge of the area can help.

Re: Extreme Programming, a Reflection

#20

Post by lmm »

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.
Post reply on HN