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

51–60 of 69 posts

Re: Extreme Programming, a Reflection

#51

Post by taeric »

jerf wrote: post #49
taeric wrote: post #47

Earlier quoted context omitted.

I still think the loose concept of "loosely coupled pieces" is a massive hand waving over the difficulty in making something multiple pieces. It is typically the goldilocks search. When do you have too many pieces, and when do you not have enough? I have yet to see a prescriptive approach to this that works. About the best I've seen is the holistic iterative approach. First make something, then look to see where you…

I disagree that it's massively difficult. I think it's a skill that has to be learned. As I get better at it, I become faster putting together something loosely coupled than tightly coupled... because while writing something big and monolithic may have a momentary short-term advantage, when it comes time to, you know, make sure it works , correctly, my system is a lot easier to verify, test, deploy, and ship than the…

I don't disagree that it is a skill that can be learned. Quite the contrary. I just feel that likely the best way to learn this skill is to first build a few systems that aren't loosely coupled first. Consider the analogy for building cars. Before you try and build a continuous transmission system, first get a direct drive one working. Then, determine what would need to be messed with to put basic gearing in place....

Now the major trick here is that this breaks down in categories that are effectively already solved. Which is why many of the examples are obnoxious to the point of unhelpful. If you know how to break something down to where it is loosely coupled parts already, I feel you should definitely do so.

Re: Extreme Programming, a Reflection

#52

Post by huherto »

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…

My recommendation on pair programming is that it is a good idea, you should try it, you should do it 5%, 10%, 20% of the time, whatever you want, I don't think is a good idea to do it 100%. I see two main benefits on pair programming.

  - Knowledge transfer. Learn new and better ways of working. IDE usage, short cuts, etc.

  - On a complex piece of software is better to have two sets of eyes checking everything.
TDD. I enjoy doing it, I am not strict on doing test first, most of the time I don't. I usually shoot for 70% coverage. Indeed, the tests take a significant part of the effort, often they are brittle and you need to refactor them, but I really think they improve your overall design, your confidence on the robustness of the system.

Re: Extreme Programming, a Reflection

#53

Post by steven2012 »

I was developing software back then when extreme programming came about. It wasn't controversial at all. In fact, everyone I knew thought it was a much better way of programming than the current waterfall method. The only problem was inertia from management, which is always the case.

Re: Extreme Programming, a Reflection

#54

Post by asdasf »

I was pretty shocked to see a programmer that delusional about XP and its influence. Then I got to the bottom and saw it was an XP snake-oil salesman writing it, not a programmer. Surprise. All 12 of those things predate XP, and most of the 12 things are situational. There is virtually never a case where following all 12 of those things makes sense. But that is exactly what XP was. It demanded you do all 12. Just saying "because some people still do some things in that list, XP mattered" when those things were being done before XP came out is absurd. "Which ones don't you do?", all of them but avoiding overtiming.

Re: Extreme Programming, a Reflection

#55

Post by dfox »

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 practice what essentially amounts to pair programming very regularly. On the other hand any kind of TDD seems to be mostly moot for projects I work on. I assume this is because most of my projects involve disparate components with continuously changing interfaces and just getting together works better than producing interface specification that is complete enough to base any tests on (and to be clear: it's not about two people being in same room and each hacking away at his component, but about both working alternatively on each component).

I'm somehow surprised that this even works well with pairing of programmer and hardware engineer, but that requires management that believes in their engineer's skills (rapid iteration and hardware tends to get very expensive very fast) and programmers that have meaningful insight into hardware.

On the other hand projects I work on are probably not very representative of anything as most of them are weird :)

Re: Extreme Programming, a Reflection

#56

Post by city41 »

I like a lot of what XP brought to the table, except pair programming. I find it's genuinely not effective most of the time. It is very effective when teaching someone. But in general I have found it to be slower, produce worse code, reduce accountability, and causes frustration. I'm currently working on a long blog post detailing my thoughts on it.

Re: Extreme Programming, a Reflection

#57

Post by FrankenPC »

I love pair programming. Frankly though, it takes several hours of committed time to be really useful. It's hard to get two production programmers to sit down together for a few hours to focus on this. To get around the time hurdle, I've proven to upper mgmt that the amount of bug fixes or efficiency improvements is easily greater than the amount of product the two alone could have achieved. There's a Tesla-ish resonance that occurs when two people are focusing on the exact same problem. LOVE IT.

Re: Extreme Programming, a Reflection

#58

Post by dlr720 »

grimer wrote: post #33

In regards to pair programming - I realized recently that I'm opposed to it just because I don't enjoy it. I don't like having someone look over your shoulder while programming, or looking over someone else's shoulder while they are programming. It is exhausting. Collaborating in front of a whiteboard for a few hours is fine - I just don't want to do it all day. I also don't like feeling guilty taking a 5 minute brea…

from my experience it's not everything or nothing. In fact I would say i have never done a XP project where we did everything, but we almost always add tests (what %, simply depends on the project), and they always gave us tremendous insights, we did some level (mostly very little) paring (on either super hard or super critical code) and it always helped get thru the code or provide what mgmt needed, more then one person to understand something that was too critical to leave to only one person. people need to enjoy what they do, and employers need to understand if you want strong talent you need both to work as a team (not shove "do it this way" down people's throats) and XP requires BUY IN. - BTW I am a CTO who has been pushing XP on all dev projects for the past 5 years and I don't code :-)

Re: Extreme Programming, a Reflection

#59

Post by pjmlp »

joshuacc wrote: post #43
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…

Why do you think that TDD prohibits you from using a whiteboard to design your algorithms and data structures beforehand? As far as I can tell, doing that work, then writing your first test is just TDD done well.

Because that is what TDD advocates sell at agile conferences, design by coding.

Re: Extreme Programming, a Reflection

#60

Post by hderms »

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…

I really appreciate your response. It's very measured and, to me, seems the result of experience, as opposed to gung-ho idealism. People need to realize that software is complicated, and that despite the fact that computers operate on unambiguous rules, that the people creating the software often can't depend on concepts in the same way. Following test-driven development fanatically is not a shortcut to designing re-usable, composable software. There is no shortcut to that.
Post reply on HN