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"!
Seven Things I Hate About Agile
111–120 of 124 posts
Re: Seven Things I Hate About Agile
#112Earlier 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?
Re: Seven Things I Hate About Agile
#113Earlier 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…
Re: Seven Things I Hate About Agile
#114I 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.
Re: Seven Things I Hate About Agile
#115Earlier 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.
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
#116Pair 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…
Re: Seven Things I Hate About Agile
#117Earlier 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…
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
#118Earlier 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!
Re: Seven Things I Hate About Agile
#119Earlier 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.
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
#120So 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.
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