Not necessarily. The idea here is that the customer has an idea about what he wants, but has only a vague idea about what he actually _needs_, and no idea about what is technologically possible. Methods like XP embrace that by allowing requirements to change over time, to account for the customer accumulating more knowledge about all three areas.
But you can nail those things down before coding begins, just through talking with them. You don't need to literally change the code completely every week - iterating a plan is much easier than iterating a codebase!
But with 2 weeks of coding, you can save yourself an hour of planning.
Is it really common for software engineers to work under these conditions? As an electrical Engineers I have plenty of deadlines and do plenty of work with PMs, but none of this daily standup and thankfully Jira was recently dropped as it was considered more trouble than it is worth (management just wanted to know the big things going on and not all things). Of course it's better than plenty of other jobs, but the co…
That's how it used to be when I started in the 90s. My first projects were pretty much like "Here is the problem. Come back when you have questions" and me and others would often work for weeks without talking to management. Now it seems a lot of companies are doing more micromanagement. I also sometimes wonder if the younger programmers need more handholding these. When I started there were almost no people with for…
The problem is that a client is paying by the hour, so going away for “weeks” to guess and “work” costs literally thousands of dollars. With XP, there would be a problem that would require weeks of obscurity to solve: it would be broken down into a smaller piece. And, you’d be working with your pair on it with frequent interaction with the PM.
There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atm…
> I followed my mentor’s advice and started to check-in at least every half day with each pair of engineers I was working with. This is monumentally bad advice. > I try to find a time when a pair does not seem to be heavily focused. Some of the cues might be they are having a casual non-work related conversation or are just returning from a break So surveill and/or eavesdrop and/or ambush. Nice. > Hadrien Raffalli is…
> So surveill and/or eavesdrop and/or ambush. Nice.
Maybe that's the idea - "He always ambushes us when we come back from a break... we'd better stop taking breaks!"
Not necessarily. The idea here is that the customer has an idea about what he wants, but has only a vague idea about what he actually _needs_, and no idea about what is technologically possible. Methods like XP embrace that by allowing requirements to change over time, to account for the customer accumulating more knowledge about all three areas.
But you can nail those things down before coding begins, just through talking with them. You don't need to literally change the code completely every week - iterating a plan is much easier than iterating a codebase!
Not necessarily, and it really depends on the customer and on the software. You feed the learnings from one iteration into the next - it's not intended to change the code completely every week, but to allow maximum flexibility in the backlog.
Is it really common for software engineers to work under these conditions? As an electrical Engineers I have plenty of deadlines and do plenty of work with PMs, but none of this daily standup and thankfully Jira was recently dropped as it was considered more trouble than it is worth (management just wanted to know the big things going on and not all things). Of course it's better than plenty of other jobs, but the co…
> As an electrical Engineers I have plenty of deadlines and do plenty of work with PMs, but none of this daily standup
Damn... is it too late to go back to college and study electrical engineering?
I don't know how you get the idea that it's forced. We're known for it, it's part of the interviewing process for Labs and most of R&D. Folks who don't want to pair generally don't apply. Of those who apply, some try it during the interview process and decide it's not for them. That is a good thing. Besides which, solo work is common too. Most of the field org works solo, Spring folks mostly work solo, I love pairing…
>>> Folks who don't want to pair generally don't apply. Of those who apply, some try it during the interview process and decide it's not for them. That... sounds like forced to me?
I'm another person who has done a fair amount of XP. Definitely some people feel this way. Some people do not. Personally, I really enjoyed it. I enjoy working with people. I enjoy shared experiences. I found the atmosphere to be challenging yet friendly. Quite often solo programming can be lonely. Sometimes you wonder what people think of your code. Sometimes you hear all too well what people think of your code -- t…
This right here. It changed my outlook on software completely. There are pains and giving folks the opportunity for change/rotation is refreshing. Software is a team sport, its a weak-link game where we must communicate and empathize in order to see clearly (often past our own egos) in order to pull one-another up. I was fortunate that good pairing hygiene was a focal point. Without that it can be disastrous mentally…
I feel you. When you pair program with someone you get to know each other deeply as programmers and people too. Not all of us can go into millitary to live dangerously with fellow soldiers, or participate in team sports, but as a weak substitue we have pair programming and high-pressure projects. I have to clarify that I enjoy pairing. It is the greatest thing when it works. But often it doesn't - it is a social activity, and so many things have to come together for that to happen. If you have a company that selects for such fit, and a culture that teaches pair hygiene, then the chances are better. Yet, I would rather reserve the freedom to choose how I work rather than be institutionalized for 8 hours a day into a specific ritual.
4) sounds like a recipe for disaster if the product is large enough. Nobody can remember everything. Heck, I start writing a text document when something gets too big for myself .
Having followed the process as described, i'd agree. If a project runs for more than a few months, you forget why decisions were made. I don't think XP in general has a great story about how to deal with this.
I'd be less worried about "forgetting" and forever worried about a manager just saying "you obviously forgot (something I just decided)". I mean it happens even when there's documentation I can pull up and say "well actually..", I'd hate to imagine otherwise.
> I followed my mentor’s advice and started to check-in at least every half day with each pair of engineers I was working with. This is monumentally bad advice. > I try to find a time when a pair does not seem to be heavily focused. Some of the cues might be they are having a casual non-work related conversation or are just returning from a break So surveill and/or eavesdrop and/or ambush. Nice. > Hadrien Raffalli is…
Pivotal is well known for having a particularly extreme point of view, bordering on forthright religious fervor, when it comes to pair programming and taking highly bureaucratic versions of Agile development to an extreme. Pivotal can deliver things to customers in spite of all this (given that it’s surely not because of all this), which sort of makes any advice published out of there fundamentally irrelevant for peo…
How are you so sure? They are so brilliant they can make great stuff despite a terrible process they choose, but they aren't smart enough to not use the process?