Live data from Hacker News

Seven Things I Hate About Agile

blog.assembla.com

111–120 of 124 posts

Re: Seven Things I Hate About Agile

#111
post #97

Earlier quoted context omitted.

Pair programming reminds me of the issue of trying to pair up for video games. Either you find somebody much better than you, or much worse. Because the spectrum is large, the chance of a good match is nil. In programming the spectrum is larger. When I've been asked to program with somebody, its always been a terrific drag on my productivity. I crawl thru the day, trying to be nice, and when they go the hell home I s…

then you need to confront your situation and resolve it satisfactorily, because staying in late to get your "real" work done is means to an end, remember you have a "life"!

Kind thought, thank you. But sometimes my life IS my startup, and thats the choice I have made.

Re: Seven Things I Hate About Agile

#112
post #86

Earlier quoted context omitted.

I like to pair with people who are as good, but I'm also happy to pair with people who are much better or worse. When it's somebody much worse (e.g., somebody new to my code base) then I'll spend a lot more time driving. As they see what to do, they jump in. Sometimes I'll force them to jump in regardless, so that they learn by doing. That's a short-term personal productivity hit, but for me it has always been a long…

In a pair-programming context, what does "my code base" mean?

Good question. I could better have written that as something like "my team's code base".

Re: Seven Things I Hate About Agile

#113
post #86

Earlier quoted context omitted.

Pair programming reminds me of the issue of trying to pair up for video games. Either you find somebody much better than you, or much worse. Because the spectrum is large, the chance of a good match is nil. In programming the spectrum is larger. When I've been asked to program with somebody, its always been a terrific drag on my productivity. I crawl thru the day, trying to be nice, and when they go the hell home I s…

I like to pair with people who are as good, but I'm also happy to pair with people who are much better or worse. When it's somebody much worse (e.g., somebody new to my code base) then I'll spend a lot more time driving. As they see what to do, they jump in. Sometimes I'll force them to jump in regardless, so that they learn by doing. That's a short-term personal productivity hit, but for me it has always been a long…

All well and good, but there is actual work to get done. In the short term, I will get more done without the friction of a 2nd person to tutor. Much more work. Order of magnitude more work.

Re: Seven Things I Hate About Agile

#114
post #2

I like how the opening point is ageism. Really classy.

Author here - I can make an observation about old people because I myself am 49 years old. I'm not making a value judgement about older people. That would be ageism. I'm observing that the attendees "agile" events tend to be older than most programmers, and even most IT staff. That's just demographics. Why is that? That affects a lot of things.

Women can be misogynistic. Where are you getting your sense of the demographics of "most programmers," anecdata?

Re: Seven Things I Hate About Agile

#115
post #97

Earlier quoted context omitted.

then you need to confront your situation and resolve it satisfactorily, because staying in late to get your "real" work done is means to an end, remember you have a "life"!

Kind thought, thank you. But sometimes my life IS my startup, and thats the choice I have made.

I was only referring to your bad "pair programming" experience, in that you felt it held you up from actually getting stuff done, that's just wasted effort.

However, my experience is that pair programming would work well in a senior/not as senior pairing, with the caveat, you need to have capacity on your projects to roll with this also technique.

regarding you choosing to sweat on your startup, fair play thats your choice, and possibly a good one if that's what you are passionate about. hopefully your end goal/mission is not just to make loads of money though!

Re: Seven Things I Hate About Agile

#116
post #7

Pair programming was invented and evangelized by developers, and are its most ardent defenders at every vendor I know that offers Agile services. ThoughtWorks' sales folks hate selling pairs, for the obvious reason that most clients don't love the idea of buying them.

Even ThoughtWorks has/had developers who don't particularly like or believe in pair programming, but go along because it comes under the company's proclaimed orthodoxy umbrella most of the time. (ex TWer, so I know whereof I speak). I used to champion pairing when I used to work at TW, and used to be puzzled at why some (very talented) TW developers thought it was all hogwash, but TW is a fine company in many ways an…

I would say 100% pair programming would be a highly draining experience! may result increased productivity, but at what cost!

Re: Seven Things I Hate About Agile

#117

Earlier quoted context omitted.

Refactoring your data structures is different though, is it not? In an RDBMS, you have to migrate your data when the schema changes, correct? If you have, say, 100 million records in Mongo DB and you decide you need to refactor your data schemas, how long will it take you to do that? The problem is that an RDBMS is very rigid typically on data input but very flexible on data output. if you change data input you MUST…

Again, I'm not seeing the problem. 100 million records may take a lot of time to update, but so what? It's not like you make major schema changes to the same data every day. If you write your code to read either format v1 or v2 and to output v2, the migration can begin gradually. When you're sure it's working well, you start a low-priority job that reads old records and migrates them. Eventually, all data is in v2, s…

When you're sure it's working well,

Translation: We cut out the time on managing our schema and sped up our development, and this meant we got to spend it all back and more managing schemaless storage!

Re: Seven Things I Hate About Agile

#118

Earlier quoted context omitted.

Again, I'm not seeing the problem. 100 million records may take a lot of time to update, but so what? It's not like you make major schema changes to the same data every day. If you write your code to read either format v1 or v2 and to output v2, the migration can begin gradually. When you're sure it's working well, you start a low-priority job that reads old records and migrates them. Eventually, all data is in v2, s…

When you're sure it's working well, Translation: We cut out the time on managing our schema and sped up our development, and this meant we got to spend it all back and more managing schemaless storage!

If you don't like NoSQL stores, don't use 'em. Either toolset is fine with an agile approach, though.

Re: Seven Things I Hate About Agile

#119
post #86

Earlier quoted context omitted.

I like to pair with people who are as good, but I'm also happy to pair with people who are much better or worse. When it's somebody much worse (e.g., somebody new to my code base) then I'll spend a lot more time driving. As they see what to do, they jump in. Sometimes I'll force them to jump in regardless, so that they learn by doing. That's a short-term personal productivity hit, but for me it has always been a long…

All well and good, but there is actual work to get done. In the short term, I will get more done without the friction of a 2nd person to tutor. Much more work. Order of magnitude more work.

In the short term? Sure, in the short term you don't need tests, either. Or readable code. Or version control. Or colleagues. Or multi-letter variable names.

Any software development approach works in the short term. In which case, do what you want. But if you're looking for a sustainable approach to building a product, sometimes you have to sacrifice short-term personal productivity to gain in the long term.

Also, "order of magnitude" is a sign you're doing it wrong. Worst case for me is circa a 30% hit; if somebody is sufficiently novice, then they're mainly along for the ride while I code and explain as I go.

Re: Seven Things I Hate About Agile

#120

So who the hell are Assembla and why should anybody care what they have to say? All I'm seeing here is a lot of misinformed ranting. Sure, there's a kernel or two of truth hidden away in there, but most good rants have that. I don't see that TFA makes any sort of interesting point or arrives at any real conclusion that's helping anybody make a decision though. Oh wait, I'm almost 40, so I guess I'm too busy decaying…

Yeah, I stopped reading at "Old People", and I am not even in that demographic. Wholesale discounting all wisdom in an entire segment of people with lots of experience in the very field you work in is rarely a good idea. I mean what's up with Knuth being so old? Some young guy should finish out TAoCP and show him how its done.

Here's my take on the "Olde Agile Coaches".

Around 2000 the stock market tanked, and a lot of these old agile coaches were seeing their retirement go away.

They didn't have any meaningful programming skills to bring to the workplace, but they needed some income.

So what did they do? Become agile coaches!

That's why most agile festivals look like an AARP convention, and why they drone on about Zen parables and radical 70s leftism.

PostAgilist

Post reply on HN