Someone who hates MS so much that they'd rather cede liberty in software design to judges and juries isn't really going to have anything constructive to say, anyway.
At what point did the government, or third parties via the courts, become the best people to decide what features you think should appear in your new software product?
At the point where the marketplace, in part due to illegal activity by Microsoft, ceased to provide the necessary checks and balances.
PhDs are meant to do research and advanced development that won't see the light of day for 5-8 years. What happens is that there is more demand for product development and that many of the PhDs end up doing it because they have to make a living somehow.
This can be true, but it is the very rare PhD who understands that they know approximately zero about writing code for production. I can't count the number of times I have been handed a steaming pile of research-grade code with the expectation that it just needs a little polish before shipping, when actually what it needs is to be given cement shoes and tossed in the river.
You and I may know that most PhDs shouldn't do product development. The problem is that they don't know it, or at least don't tell their bosses.
Well, if your job is to Manage people who are doing a task, and you put forth an image that shoves your own cultural meme right into their faces, that's confrontational, and that means you're not doing your job.
We all have cultural baggage. That you think of some as "neutral" suggests you are blind to your own biases.
A good manager should carry themself in a fashion that wouldn't shock or offend ANYONE they might be called upon to administer, be they a middle aged good christian graphic designer or a tattoo bearing goth hacker who worships the devil.
Yes. And they do that by being authentic and respectful, not by adopting the particular set of signifiers that you find matches your biases.
The Economist? Hard to take them seriously. They predicted $5 per barrel oil when price was $10.
What? They've been writing for 150 years and it's hard to take them seriously because in 1999 they once guessed wrong about the future? You ignore, of course, that they owned up to the mistake by the end of the year. They examined the reasons behind it, and looked at several other mistaken predictions as well in an article titled, "Goofs: We wuz wrong".
Personally, I think it's great that they're willing to be contrarian, to make clear predictions about the future, and to own up when they get it wrong. A lot of the value in The Economist comes from their willingness to think about the news that they're reporting. A magazine that speculates on future possibilities and gets it 100% right means that they're being far too conservative to be interesting or useful to me. I want them to challenge me to think and give me facts to do it with, not be magically right all the time.
Of course, their other big prediction that year that failed to pan out was that the tech bubble was overdue to burst, at a time when many business magazines were still in a "OMG Dow 40000!!! Free ponies for all!" frenzy. That one they nailed, so perhaps they should get a little credit there.
There's a long-standing principle of debate that says that he who wants to propose a change has the burden of proof.
Great. If I ever propose a change, I'll keep that in mind. As far as I recall in this discussion, I'm telling you what works for me and why I think it works. You have questions, let me know.
In my 20+ years of experience I've never heard management say "The team is going to vote on what methodology to use".
I guess if you've never had good managers that treat your team like professionals, it's no wonder you're suspicious about methodologies. Me, I'm used to employers telling me what they want done and getting out of the way, so to me it's all just things I might try.
There's a big difference between having a theory about aspects of code and having a theory based on human behavior. If there's as much evidence that Agile methods are better than there is for object orientation or simple designs I certainly haven't heard about it.
Hmmm, I guess I missed the double-blind studies on object orientation. And I don't see the big difference; in both cases I'm saying what works for me and why. You may use that information or not. It looks like not, which is fine by me.
If methodolgies were typically optional on a person-by-person basis, I'd have no problem with them, but that's almost never the case. So I'm not arguing against people doing what works for them, I arguing for the right to do things the way that works best for me.
Hmmm... I guess I'm not seeing how that's possible. If you're working with other people, then you need to agree on some sort of way of working together. I think if you're working solo, you should certainly have the right to do work the way you see fit. And I think a team also has the right to do work the way they see fit.
If there's solid, non-anecdotal evidence that a new methodology is better, I'll adopt it. Otherwise, I'll do it my own way when I'm allowed to.
Could you point me to the solid, non-anecdotal evidence you based your previous methodology choices on? I'd be fascinated to see it.
I think all of these arguments are rather weak. They're all based on an unproven theory of how people are supposed to think, act, and feel.
Well, they're actually based on my discussions with dozens of people who have done TDD. I agree I don't have scientific proof. But I don't feel any obligation to get some, any more than I need scientific proof of the value of object orientation, clear naming, preferring simple designs over complex ones, or the particular knot I use tying my shoes. I do what works for me, and I'm telling you why I think it works. If you want scientific proof before trying out any new technique, that's your issue, not mine.
Just as those managing a TDD project can require that tests be written before code, the manager of a non-TDD project can require unit test for all modules before check-in.
A manager can't require TDD. It's impossible to enforce unless you sit there round the clock, and good managers don't get so much in the business of professionals anyhow. All the people I know who do TDD do it because in their opinion as professionals it's the best way to get work done.
What I find pointless is rewriting unit tests again and again to follow the rules when writing the unit test once is just as effective.
So you've tried it both ways for a few months and concluded that one is just as effective as the other? In which case, that's great. You should carry on doing what works best for you. No scientific evidence needed, right?
On the other hand, if you haven't given TDD a serious try, your conclusion above is just a theory. Which you're welcome to; if you're happy doing what you're doing, then carry on ignoring TDD. I'm always looking for ways to boost my skills, but I'm sure that's not true for everybody.
Like, I've been saved, you can be too, just ask? You're not the first say this, I'm wondering, is this some sort of religious thing? Because you all really sound alike... do it our way or the highway, there's no better way, if you don't like it then you're not doing it properly, and all that stuff... ?!?!?
No, it's not a religious thing. I agree that some people are dogmatic about it and I agree those people are annoying. For me it's a pragmatic thing. I want to make good stuff, and this is the best way I have found to make good stuff. When I find better ways, I will do those. For example, domain-driven design is something I've added to my toolbox more recently.
The "if you don't like it you're not doing it properly" is an interesting point. Every single time I have talked to somebody who hated pair programming, I find out they were doing it wrong. Generally they are doing "one person watching another programming" which is a boring waste of time. Or they tried "arguing with an asshole all day programming" which is also not so fun. All of the people I have personally introduced to pair programming ended up liking it, and this includes a wide variety of engineers. So after going through the "I hate pair progrmaming" discussion twenty or thirty times, my starting assumption is indeed that people who hate it have probably never tried what I think of as pair programming. Sorry if you don't like that, but I'm not sure what else to do.
But if you don't want to know about it, that's fine by me. I was just offering. It's not like I get a bounty from L. Ron Hubbard or anything. I've got plenty to do otherwise.
where I am, by way of my profession, pictured and treated as a child who doesn't know better and so must be controlled.
I think that one Beck quote is getting taken out of context, and it isn't from any of the XP books. The methods are just the opposite in spirit from the one you describe above. XP teams are supposed to be self-managing in most ways. The main non-developer role in XP is a product manager whose only job is to say what features are wanted and in what order. All technical matters (including all estimation) are the strict provenance of the team of developers.
Right now I'm doing an agile transition with one team where the manager spent all his time breaking down the features into little technical bits and parcelling them out, micromanaging the developer work queues. Three months in he's stopped doing that. He just says what features are top priortity and the team parcels out the work as they see fit, often in non-obvious ways. They're happy because they're more in control of their lives; the manager's happy because he can focus on things he things are more important.
There's actually a heavy debate in the XP world about "rules" at all. Beck regrets ever having phrased things so strongly because some people took them too seriously. Others like Jeffries feel that rules are a useful starting point, like the rules you give to a beginning skier, knowing that they will leave most of them behind on the bunny slopes as they get the spirit behind the rules. But all of them agree that by-the-book XP is meant as a starting point rather than an end result.
You'll note that there's no XP certification organization, and no official checklist that tells you whether or not you're doing XP. That's entirely on purpose. XP is meant as a set of tools for people to be more productive with, not a stick for managers to beat employees with.
If you look back at this thread, what we are really talking about is the alleged benefits of TDD.
Oh, and responding to what I now think to be your actual point, TDD itself also makes people more likely to test and test well. Why? From my experience, I see three reasons:
The first is a psychological one. If you write the test first and then make it pass, it feels good. If you're doing TDD properly, your day is a series of small wins, with occasional setbacks. Because you have the safety net of tests, the setbacks are generally small, so your frustration level is low. This is much, much more pleasant than writing tests afterward.
The second is the that you can't unlearn something. Once you have written the code, you already have a number of notions and assumptions about the problem. For me at least this makes it harder to come at the problem with the fresh perspective that lets me cover all the interesting angles in my tests.
The third is that after-the-fact testing can feel kinda pointless. I already think the code works, so the best case is that the tests don't tell me anything. Or, worse, they tell me that I screwed up at some point in the past and now need to rework things. Either way, it's dispiriting.
One of the things that XP and TDD types talk about is being "test infected". Once hooked on TDD, people very rarely go back. Whereas with with post-construction testing, it's usually something that people think they should do, or started to do but gave up. I don't know that I have ever me an engineer who has a substantial system with coverage like I'm used to, which is a 1:1 ratio between test and production code and upwards of 95% measured test coverage. I'm sure they must exist, but the only people I know who code like that are all on XP teams.
If you look back at this thread, what we are really talking about is the alleged benefits of TDD
Got it. Sorry for the confusion.
As far as the idea of paired programming as a way to keep programmers in line is concerned, that goal could probably be acheived without using up an extra programmer. Without a lot of training a clerical worker could probably insure that unit tests were written first, etc.
This is true, but it would miss about 90% of the value in pairing. Pairing isn't a way to keep programmers in line. It's a way to do good work. A clerical worker can't give me good design feedback, or point out a missing edge case in the tests, or nab the keyboard and press forward when I'm stuck. They sure can't sure show me the way they did it on another project, a way I've never seen before. And a clerical worker can't give the feeling of team effort. The best they can do is nag, which I expect would grow quickly tiresome.
As has been noted by others in this discussion, the "incentive to get colleagues to do things 'right'" can be a source of irritation and inefficency. Some programmers have the same traits as retired ladies that sit on their porch looking for tiny infractions of the homeowner association rules.
It's possible that some programmers are congenitally unsuited to working on teams. But in my experience, a close team environment helps people more quickly learn the right balance between fussiness and getting things done. And a short-cycle iterative process lowers the stakes. We solved a lot of problems by saying, "Well, that's an interesting point. Let's try it the easy way for a couple of weeks and see how it goes." If the persnickety person was right, we'd all say so. If not, they'd learn that the thing they were worried about wasn't such a big deal. Either way, we all won.
Extreme Programming was invented by programmers; they felt it was the best way for them to work on the project they were doing. All of the main Extreme Programming proponents still write code regularly, and some even blog in detail about coding.
I'm a programmer, and I love it. If you want to know why, don't hesitate to ask.
NOT as a lab rat for "extreme programming" or whatever buzzword-laden feelgood bullshit management scheme comes along this week.
And maybe that's the problem. I'm a developer, and when reading about Extreme Programming I said, "This is either crazy or brilliant, and I have to find out which." So got a client to try it, and it worked wonderfully for me. Managers will never really get it, because it was devleoped by programmers and for programmers. So if they were to explain it and push for it, I imagine it would sound retarded.
This is common to all methodologies. There's nothing in XP that is more likely to get individuals to follow the rules than there is in any other approach.
That's a reasonable thing to think, but it's incorrect. In fact, it's the thing that makes XP different from almost any other method.
Pairing is one obvious thing: for a pair to slack requires a conspiracy rather than an accident or a moment of weakeness. Common code ownership is a second: if you are working as a team and truly share the code base, you will have plenty of incentive to get your colleagues to do things right. Retrospectives are another; if the team continuously adjusts the process to improve things and be useful, people are more likely to follow it. And short iteration and frequent releases keep people honest by exposing the work often to managerial evaluation and real-world conditions.
Basically, XP closes and tightens a lot of feedback loops that get left open or are too long in other processes. This gives you the incentive to do great work.
What's wrong with the programming surgical team described in the mythical man month? Collective ownership seems to be deliberately creating more communication overhead for programmers. In other words, what does XP bring to the table that is useful instead of just different?
To my mind, several things:
On a surgical team, it's only the surgeon who has much fun. Ask people who actually work in surgery; the stereotypical surgeon is an annoying prima donna.
Surgery does not happen without the surgeon; on teams with collective ownership, people can take vacations as needed.
Collective-ownership teams maximize use of individual skills. On a day when there's a DB-releated issue the database maven takes the lead. When it's system performance, the former sysadmin steps up.
Collective-ownership teams are more flexible; they can work as one unified team or several smaller ones depending on workload.
Your truck factor is much better.
The overhead is very small if, as XP recommends, you are pairing and change your pair partner every few hours.
Of course, perhaps there are surgical-style teams that do better than the ones I've experienced. But for me, I love the collective ownership.
agile software development is simply a way to say "code now, we'll get you the specs later"
That's almost right. Instead, it's "Start the project now, and we'll get you the specs as you need them." I will never spend entire meetings arguing over the precise meeting of section 5.2.3.1.5 pargraph 4 in a 500-page spec again. I will never again spend months overdiscussing possible future projects without writing any code. I am pleased as fucking punch.
Instead, every week we pick the things we're going to do off a stack of index cards. We talk about them in front of a whiteboard until the devs feel like we have enough to go write code. Then when I realize I need more info or want to show something for feedback I look up at a product manager and maybe wave one hand to get his attention. Bada-boom, question answered, and I'm back to coding. Before we declare any unit of work done we get the product managers to sign off that it's done. On Friday, we present the new version of the program to all who care to see it, and maybe we release it, too. On Monday, we start again.
I actually found it far more tedious and mind-numbingly boring then dedicated code reviews myself.
Were you sitting with equal access to the screen and keyboard? Was control changing hands at least every ten minutes, and hopefully every five? Were you doing test-driven development? If not, I'm not surprised. Done right, I think it's much more fun, and much more productive.
You'll notice that firms who force crap like XP (but not limited to) onto coders fail in the long term. (or at least from a technical perspective they fail) I can also guarantee that sitting two people down to code on one terminal is a quick way to cut production and ramp up cost in a big way. Even the best minds dont always work well together.
You have any data to back that up? My project stats and the studies on pair programming show the opposite.
Whenever I have someone watching me, and they point out the mistakes, telling me to go and correct something, I often lose my train of thought.
This is a typical novice problem, but doesn't happen much with experience pair programmers. Navigators learn to shut up about missing semicolons and such, or at least to wait until they're sure you've missed it. And drivers learn to talk more about what they're doing. And since good pairing involves the keyboard changing hands often, everybody talks more so that the pair is heading in the same direction generally.
It definitely takes work to learn, but having had experience both ways, I now really miss pairing when I'm working solo. And I'm not the only one. Compare these two blog posts:
But real engineering requires planning and clear interface definitions, and XP -- almost to the point of being pathological -- attempts to avoid planning as much as possible by subsitituting endless chatter and tremendous time wasting repeatedly reimplementing what could have been done right the first time.
From the stats on my projects, doing it XP-style is not a waste of time, and is in fact very efficient. Why? Because XP postpones design work until the last responsible moment. That sounds crazy until you realize that the beginning of the project is when you will know the very least, and the end is when you know the most. That's true about everything on the project: the domain, the requirements, the people involved, the technologies used, everything. The best decisions are the ones with the most information, and therefore the latest ones.
For things that can be done perfectly the first time, maybe XP isn't the right process. But a project where I learned absolutely nothing the whole way through would be terribly dull, so I'd never work on one of those anyhow.
It works for me. Indeed, from your comments, I'm not sure that what people told you was Extreme Programming was what I would call Extreme Programming, so it's not shocking we'd have pretty different opinions.
No company in their right minds wants to pay for TWO programmers to do a single job.
Any company in their right minds wants to get the best results. I'm vastly more productive while pairing. Why? As they say, "Two heads are better than one." The hard part in programming isn't the typing, it's the thinking. Pairing gives me third-draft code in first-draft time.
For the last full XP project I did, we paired all the time and ended up with as much test code as production code. But comparing with the metrics in McConnell's Rapid Development we were in the top 10% in terms of production-code productivity. And after 36 developer-months of work, we had a total of two bugs in production, both quickly fixed.
As with any other method, it assumes all the specs and implementation have been worked out before the code is even written.
That's entirely incorrect, and makes me think that whatever you were doing, it wasn't Extreme Programming. Go read one of the books on Test-Driven Development (like the one from Beck) to see how it should actually work.
The project I mention above was a startup, where we had very little worked out in advance, and where requirements changed weekly as we got new data from market or user research, as competitors got up to new things, or as people had great new ideas. In a typical environment, the developers would have killed the suits, as we never would have gotten to finish anything. As it was, we had a great relationship. Every week they'd pick the most important things to do and we'd do 'em, figuring out the requirements as needed. I loved it. All of the devs have gone on to become big XP advocates, as none of us have ever had things go so well.
nobody has the freedom to write experimental throwaway code to even see if their approach is even feasible in the coding, or, if programming a device, if the device will even work with the approach being made (for you people not in the embedded world, most device datasheets are incorrect and seldom get corrected).
Are you serious? When you don't know that something is feasable, XP teams do throwaway code as research. Often they do what are known as "spikes", which are simple end-to-end proofs of concept. You write just enough to prove that the approach is reasonable, then toss it out and do real development. And the heart of XP is short release cycles and heavy testing, so you validate in the real environment as often as possible.
I don't do much embedded work, but there are plenty of XP teams that do. I know of one that does medical devices and another that does machine vision systems for manufacturing. The devs in both companies love it.
While its great at letting the mundane functions be rewritten (refactored) as many times as possible, it gives a mechanism where newer features are *always* put off (by managers usually) indefinitely....its an illusion, under a few managers, that the programmers will ever get to implement the newer features wanted by customers (its amazing how most new features are always rated as low priority by someone other than the customer....even more amazing about how many 'stories' aren't written by the customer.).
If your managers are picking the wrong things to do, that's not a problem that XP can solve; no process is proof against putting idiots in charge. But the typical XP project is supposed to do new work every week, and it's supposed to do the things with the highest business value first. Refactoring should never show up in the feature list; only things of customer value are supposed to be scheduled in the work queue, and refactoring takes place as needed to acommodate new work.
Even in the XP books it is explained that XP is not meant to work for every single software environment/situation....yet there
I doubt the dead, were they asked about it before they died, would want us to dwell on how we described their death. Rather, I think they'd prefer to have us remember who they were and what they did in life.
Personally, I prefer to be remembered as a persnickety old coot who despised euphemism and bullshit. So for the record, when I'm dead, I insist that my friends admonish anybody who describes me as "passing", "in a better place", or having "gone to Jesus". I will, however, accept, "pushing up the daises" or "worm food".
Of course, I've already made arrangements for the open bar at my wake, so perhaps I'm a little untraditional here.
The point is, if you're going to use the road, be it in a car or on a bicycle, obey the rules and use common courtesy. If you're unable to pedal hard enough to go the speed limit, get off the road and use the designated bike paths or use the side of the road, not the middle of the lane. And don't get pissed when I honk my horn at you because you're holding up traffic by being an idiot.
I completely agree with your first sentence, and disagree vigorously with the rest. Slower traffic, be it car or bike, should absolutely yield to let faster traffic pass. But cyclists are still traffic, and in places without good bike paths, the safest place to ride is often in the middle of the lane. Speed comes second to safety. At least in California, it's the law, and you see signs like this to remind impatient drivers of that.
Granted, but this was a hit-and-run. That means that after hitting him, the driver drove off to avoid having to face the consequences, probably lengthening the time it took for help to arrive. That isn't an error, it's a deliberate, selfish attempt to get himself off the hook.
Let me be clear: I'm not condoning this, I think it was terribly wrong, and I hope the hit-and-run driver is caught and does time, no matter what the explanation. As an avid cyclist who has been hit a couple of times, I take these things pretty personally.
However, we shouldn't be quick to judge the driver. People do crazy things in the heat of the moment. It's possible that the culprit is a perfectly nice person who had a moment of inattention followed by a moment of panic, and is now paralyzed with fear and remorse. The fight-or-flight reflex is a poweful one. It's also possible, of course, that the culprit is a sociopath who giggled on the way home. We don't know, and shouldn't assume.
We also should be careful with our judgements for another reason: what we hope we will do in a crisis is no guarantee of what we'll actually do. A friend of mine is doing her medical residency right now, and there's a reason that new doctors spend three years practicing in punishing conditions and under close supervision. It's because when the shit comes down you need deeply established habits to fall back on. Good character and education aren't enough. Without those habits, it's a roll of the dice.
Slashdot Mirror
Someone who hates MS so much that they'd rather cede liberty in software design to judges and juries isn't really going to have anything constructive to say, anyway.
[X] Not interested in arguing with ranting loon
You can say:
[ ] Yes
[ ] No
Because it really is that simple.
[X] Not interested in arguing with ranting loon
At what point did the government, or third parties via the courts, become the best people to decide what features you think should appear in your new software product?
At the point where the marketplace, in part due to illegal activity by Microsoft, ceased to provide the necessary checks and balances.
PhDs are meant to do research and advanced development that won't see the light of day for 5-8 years. What happens is that there is more demand for product development and that many of the PhDs end up doing it because they have to make a living somehow.
This can be true, but it is the very rare PhD who understands that they know approximately zero about writing code for production. I can't count the number of times I have been handed a steaming pile of research-grade code with the expectation that it just needs a little polish before shipping, when actually what it needs is to be given cement shoes and tossed in the river.
You and I may know that most PhDs shouldn't do product development. The problem is that they don't know it, or at least don't tell their bosses.
Well, if your job is to Manage people who are doing a task, and you put forth an image that shoves your own cultural meme right into their faces, that's confrontational, and that means you're not doing your job.
We all have cultural baggage. That you think of some as "neutral" suggests you are blind to your own biases.
A good manager should carry themself in a fashion that wouldn't shock or offend ANYONE they might be called upon to administer, be they a middle aged good christian graphic designer or a tattoo bearing goth hacker who worships the devil.
Yes. And they do that by being authentic and respectful, not by adopting the particular set of signifiers that you find matches your biases.
The Economist? Hard to take them seriously. They predicted $5 per barrel oil when price was $10.
What? They've been writing for 150 years and it's hard to take them seriously because in 1999 they once guessed wrong about the future? You ignore, of course, that they owned up to the mistake by the end of the year. They examined the reasons behind it, and looked at several other mistaken predictions as well in an article titled, "Goofs: We wuz wrong".
Personally, I think it's great that they're willing to be contrarian, to make clear predictions about the future, and to own up when they get it wrong. A lot of the value in The Economist comes from their willingness to think about the news that they're reporting. A magazine that speculates on future possibilities and gets it 100% right means that they're being far too conservative to be interesting or useful to me. I want them to challenge me to think and give me facts to do it with, not be magically right all the time.
Of course, their other big prediction that year that failed to pan out was that the tech bubble was overdue to burst, at a time when many business magazines were still in a "OMG Dow 40000!!! Free ponies for all!" frenzy. That one they nailed, so perhaps they should get a little credit there.
There's a long-standing principle of debate that says that he who wants to propose a change has the burden of proof.
Great. If I ever propose a change, I'll keep that in mind. As far as I recall in this discussion, I'm telling you what works for me and why I think it works. You have questions, let me know.
In my 20+ years of experience I've never heard management say "The team is going to vote on what methodology to use".
I guess if you've never had good managers that treat your team like professionals, it's no wonder you're suspicious about methodologies. Me, I'm used to employers telling me what they want done and getting out of the way, so to me it's all just things I might try.
There's a big difference between having a theory about aspects of code and having a theory based on human behavior. If there's as much evidence that Agile methods are better than there is for object orientation or simple designs I certainly haven't heard about it.
Hmmm, I guess I missed the double-blind studies on object orientation. And I don't see the big difference; in both cases I'm saying what works for me and why. You may use that information or not. It looks like not, which is fine by me.
If methodolgies were typically optional on a person-by-person basis, I'd have no problem with them, but that's almost never the case. So I'm not arguing against people doing what works for them, I arguing for the right to do things the way that works best for me.
Hmmm... I guess I'm not seeing how that's possible. If you're working with other people, then you need to agree on some sort of way of working together. I think if you're working solo, you should certainly have the right to do work the way you see fit. And I think a team also has the right to do work the way they see fit.
If there's solid, non-anecdotal evidence that a new methodology is better, I'll adopt it. Otherwise, I'll do it my own way when I'm allowed to.
Could you point me to the solid, non-anecdotal evidence you based your previous methodology choices on? I'd be fascinated to see it.
I think all of these arguments are rather weak. They're all based on an unproven theory of how people are supposed to think, act, and feel.
Well, they're actually based on my discussions with dozens of people who have done TDD. I agree I don't have scientific proof. But I don't feel any obligation to get some, any more than I need scientific proof of the value of object orientation, clear naming, preferring simple designs over complex ones, or the particular knot I use tying my shoes. I do what works for me, and I'm telling you why I think it works. If you want scientific proof before trying out any new technique, that's your issue, not mine.
Just as those managing a TDD project can require that tests be written before code, the manager of a non-TDD project can require unit test for all modules before check-in.
A manager can't require TDD. It's impossible to enforce unless you sit there round the clock, and good managers don't get so much in the business of professionals anyhow. All the people I know who do TDD do it because in their opinion as professionals it's the best way to get work done.
What I find pointless is rewriting unit tests again and again to follow the rules when writing the unit test once is just as effective.
So you've tried it both ways for a few months and concluded that one is just as effective as the other? In which case, that's great. You should carry on doing what works best for you. No scientific evidence needed, right?
On the other hand, if you haven't given TDD a serious try, your conclusion above is just a theory. Which you're welcome to; if you're happy doing what you're doing, then carry on ignoring TDD. I'm always looking for ways to boost my skills, but I'm sure that's not true for everybody.
Like, I've been saved, you can be too, just ask? You're not the first say this, I'm wondering, is this some sort of religious thing? Because you all really sound alike... do it our way or the highway, there's no better way, if you don't like it then you're not doing it properly, and all that stuff... ?!?!?
No, it's not a religious thing. I agree that some people are dogmatic about it and I agree those people are annoying. For me it's a pragmatic thing. I want to make good stuff, and this is the best way I have found to make good stuff. When I find better ways, I will do those. For example, domain-driven design is something I've added to my toolbox more recently.
The "if you don't like it you're not doing it properly" is an interesting point. Every single time I have talked to somebody who hated pair programming, I find out they were doing it wrong. Generally they are doing "one person watching another programming" which is a boring waste of time. Or they tried "arguing with an asshole all day programming" which is also not so fun. All of the people I have personally introduced to pair programming ended up liking it, and this includes a wide variety of engineers. So after going through the "I hate pair progrmaming" discussion twenty or thirty times, my starting assumption is indeed that people who hate it have probably never tried what I think of as pair programming. Sorry if you don't like that, but I'm not sure what else to do.
But if you don't want to know about it, that's fine by me. I was just offering. It's not like I get a bounty from L. Ron Hubbard or anything. I've got plenty to do otherwise.
where I am, by way of my profession, pictured and treated as a child who doesn't know better and so must be controlled.
I think that one Beck quote is getting taken out of context, and it isn't from any of the XP books. The methods are just the opposite in spirit from the one you describe above. XP teams are supposed to be self-managing in most ways. The main non-developer role in XP is a product manager whose only job is to say what features are wanted and in what order. All technical matters (including all estimation) are the strict provenance of the team of developers.
Right now I'm doing an agile transition with one team where the manager spent all his time breaking down the features into little technical bits and parcelling them out, micromanaging the developer work queues. Three months in he's stopped doing that. He just says what features are top priortity and the team parcels out the work as they see fit, often in non-obvious ways. They're happy because they're more in control of their lives; the manager's happy because he can focus on things he things are more important.
There's actually a heavy debate in the XP world about "rules" at all. Beck regrets ever having phrased things so strongly because some people took them too seriously. Others like Jeffries feel that rules are a useful starting point, like the rules you give to a beginning skier, knowing that they will leave most of them behind on the bunny slopes as they get the spirit behind the rules. But all of them agree that by-the-book XP is meant as a starting point rather than an end result.
You'll note that there's no XP certification organization, and no official checklist that tells you whether or not you're doing XP. That's entirely on purpose. XP is meant as a set of tools for people to be more productive with, not a stick for managers to beat employees with.
If you look back at this thread, what we are really talking about is the alleged benefits of TDD.
Oh, and responding to what I now think to be your actual point, TDD itself also makes people more likely to test and test well. Why? From my experience, I see three reasons:
The first is a psychological one. If you write the test first and then make it pass, it feels good. If you're doing TDD properly, your day is a series of small wins, with occasional setbacks. Because you have the safety net of tests, the setbacks are generally small, so your frustration level is low. This is much, much more pleasant than writing tests afterward.
The second is the that you can't unlearn something. Once you have written the code, you already have a number of notions and assumptions about the problem. For me at least this makes it harder to come at the problem with the fresh perspective that lets me cover all the interesting angles in my tests.
The third is that after-the-fact testing can feel kinda pointless. I already think the code works, so the best case is that the tests don't tell me anything. Or, worse, they tell me that I screwed up at some point in the past and now need to rework things. Either way, it's dispiriting.
One of the things that XP and TDD types talk about is being "test infected". Once hooked on TDD, people very rarely go back. Whereas with with post-construction testing, it's usually something that people think they should do, or started to do but gave up. I don't know that I have ever me an engineer who has a substantial system with coverage like I'm used to, which is a 1:1 ratio between test and production code and upwards of 95% measured test coverage. I'm sure they must exist, but the only people I know who code like that are all on XP teams.
If you look back at this thread, what we are really talking about is the alleged benefits of TDD
Got it. Sorry for the confusion.
As far as the idea of paired programming as a way to keep programmers in line is concerned, that goal could probably be acheived without using up an extra programmer. Without a lot of training a clerical worker could probably insure that unit tests were written first, etc.
This is true, but it would miss about 90% of the value in pairing. Pairing isn't a way to keep programmers in line. It's a way to do good work. A clerical worker can't give me good design feedback, or point out a missing edge case in the tests, or nab the keyboard and press forward when I'm stuck. They sure can't sure show me the way they did it on another project, a way I've never seen before. And a clerical worker can't give the feeling of team effort. The best they can do is nag, which I expect would grow quickly tiresome.
As has been noted by others in this discussion, the "incentive to get colleagues to do things 'right'" can be a source of irritation and inefficency. Some programmers have the same traits as retired ladies that sit on their porch looking for tiny infractions of the homeowner association rules.
It's possible that some programmers are congenitally unsuited to working on teams. But in my experience, a close team environment helps people more quickly learn the right balance between fussiness and getting things done. And a short-cycle iterative process lowers the stakes. We solved a lot of problems by saying, "Well, that's an interesting point. Let's try it the easy way for a couple of weeks and see how it goes." If the persnickety person was right, we'd all say so. If not, they'd learn that the thing they were worried about wasn't such a big deal. Either way, we all won.
Really, wtf?!? Who comes up with this shite!?!
Extreme Programming was invented by programmers; they felt it was the best way for them to work on the project they were doing. All of the main Extreme Programming proponents still write code regularly, and some even blog in detail about coding.
I'm a programmer, and I love it. If you want to know why, don't hesitate to ask.
NOT as a lab rat for "extreme programming" or whatever buzzword-laden feelgood bullshit management scheme comes along this week.
And maybe that's the problem. I'm a developer, and when reading about Extreme Programming I said, "This is either crazy or brilliant, and I have to find out which." So got a client to try it, and it worked wonderfully for me. Managers will never really get it, because it was devleoped by programmers and for programmers. So if they were to explain it and push for it, I imagine it would sound retarded.
This is common to all methodologies. There's nothing in XP that is more likely to get individuals to follow the rules than there is in any other approach.
That's a reasonable thing to think, but it's incorrect. In fact, it's the thing that makes XP different from almost any other method.
Pairing is one obvious thing: for a pair to slack requires a conspiracy rather than an accident or a moment of weakeness. Common code ownership is a second: if you are working as a team and truly share the code base, you will have plenty of incentive to get your colleagues to do things right. Retrospectives are another; if the team continuously adjusts the process to improve things and be useful, people are more likely to follow it. And short iteration and frequent releases keep people honest by exposing the work often to managerial evaluation and real-world conditions.
Basically, XP closes and tightens a lot of feedback loops that get left open or are too long in other processes. This gives you the incentive to do great work.
To my mind, several things:
Of course, perhaps there are surgical-style teams that do better than the ones I've experienced. But for me, I love the collective ownership.
agile software development is simply a way to say "code now, we'll get you the specs later"
That's almost right. Instead, it's "Start the project now, and we'll get you the specs as you need them." I will never spend entire meetings arguing over the precise meeting of section 5.2.3.1.5 pargraph 4 in a 500-page spec again. I will never again spend months overdiscussing possible future projects without writing any code. I am pleased as fucking punch.
Instead, every week we pick the things we're going to do off a stack of index cards. We talk about them in front of a whiteboard until the devs feel like we have enough to go write code. Then when I realize I need more info or want to show something for feedback I look up at a product manager and maybe wave one hand to get his attention. Bada-boom, question answered, and I'm back to coding. Before we declare any unit of work done we get the product managers to sign off that it's done. On Friday, we present the new version of the program to all who care to see it, and maybe we release it, too. On Monday, we start again.
I love it.
I actually found it far more tedious and mind-numbingly boring then dedicated code reviews myself.
Were you sitting with equal access to the screen and keyboard? Was control changing hands at least every ten minutes, and hopefully every five? Were you doing test-driven development? If not, I'm not surprised. Done right, I think it's much more fun, and much more productive.
You'll notice that firms who force crap like XP (but not limited to) onto coders fail in the long term. (or at least from a technical perspective they fail) I can also guarantee that sitting two people down to code on one terminal is a quick way to cut production and ramp up cost in a big way. Even the best minds dont always work well together.
You have any data to back that up? My project stats and the studies on pair programming show the opposite.
This is a typical novice problem, but doesn't happen much with experience pair programmers. Navigators learn to shut up about missing semicolons and such, or at least to wait until they're sure you've missed it. And drivers learn to talk more about what they're doing. And since good pairing involves the keyboard changing hands often, everybody talks more so that the pair is heading in the same direction generally.
It definitely takes work to learn, but having had experience both ways, I now really miss pairing when I'm working solo. And I'm not the only one. Compare these two blog posts:
But real engineering requires planning and clear interface definitions, and XP -- almost to the point of being pathological -- attempts to avoid planning as much as possible by subsitituting endless chatter and tremendous time wasting repeatedly reimplementing what could have been done right the first time.
From the stats on my projects, doing it XP-style is not a waste of time, and is in fact very efficient. Why? Because XP postpones design work until the last responsible moment. That sounds crazy until you realize that the beginning of the project is when you will know the very least, and the end is when you know the most. That's true about everything on the project: the domain, the requirements, the people involved, the technologies used, everything. The best decisions are the ones with the most information, and therefore the latest ones.
For things that can be done perfectly the first time, maybe XP isn't the right process. But a project where I learned absolutely nothing the whole way through would be terribly dull, so I'd never work on one of those anyhow.
It works for me. Indeed, from your comments, I'm not sure that what people told you was Extreme Programming was what I would call Extreme Programming, so it's not shocking we'd have pretty different opinions.
No company in their right minds wants to pay for TWO programmers to do a single job.
Any company in their right minds wants to get the best results. I'm vastly more productive while pairing. Why? As they say, "Two heads are better than one." The hard part in programming isn't the typing, it's the thinking. Pairing gives me third-draft code in first-draft time.
For the last full XP project I did, we paired all the time and ended up with as much test code as production code. But comparing with the metrics in McConnell's Rapid Development we were in the top 10% in terms of production-code productivity. And after 36 developer-months of work, we had a total of two bugs in production, both quickly fixed.
As with any other method, it assumes all the specs and implementation have been worked out before the code is even written.
That's entirely incorrect, and makes me think that whatever you were doing, it wasn't Extreme Programming. Go read one of the books on Test-Driven Development (like the one from Beck) to see how it should actually work.
The project I mention above was a startup, where we had very little worked out in advance, and where requirements changed weekly as we got new data from market or user research, as competitors got up to new things, or as people had great new ideas. In a typical environment, the developers would have killed the suits, as we never would have gotten to finish anything. As it was, we had a great relationship. Every week they'd pick the most important things to do and we'd do 'em, figuring out the requirements as needed. I loved it. All of the devs have gone on to become big XP advocates, as none of us have ever had things go so well.
nobody has the freedom to write experimental throwaway code to even see if their approach is even feasible in the coding, or, if programming a device, if the device will even work with the approach being made (for you people not in the embedded world, most device datasheets are incorrect and seldom get corrected).
Are you serious? When you don't know that something is feasable, XP teams do throwaway code as research. Often they do what are known as "spikes", which are simple end-to-end proofs of concept. You write just enough to prove that the approach is reasonable, then toss it out and do real development. And the heart of XP is short release cycles and heavy testing, so you validate in the real environment as often as possible.
I don't do much embedded work, but there are plenty of XP teams that do. I know of one that does medical devices and another that does machine vision systems for manufacturing. The devs in both companies love it.
While its great at letting the mundane functions be rewritten (refactored) as many times as possible, it gives a mechanism where newer features are *always* put off (by managers usually) indefinitely....its an illusion, under a few managers, that the programmers will ever get to implement the newer features wanted by customers (its amazing how most new features are always rated as low priority by someone other than the customer....even more amazing about how many 'stories' aren't written by the customer.).
If your managers are picking the wrong things to do, that's not a problem that XP can solve; no process is proof against putting idiots in charge. But the typical XP project is supposed to do new work every week, and it's supposed to do the things with the highest business value first. Refactoring should never show up in the feature list; only things of customer value are supposed to be scheduled in the work queue, and refactoring takes place as needed to acommodate new work.
Even in the XP books it is explained that XP is not meant to work for every single software environment/situation....yet there
I doubt the dead, were they asked about it before they died, would want us to dwell on how we described their death. Rather, I think they'd prefer to have us remember who they were and what they did in life.
Personally, I prefer to be remembered as a persnickety old coot who despised euphemism and bullshit. So for the record, when I'm dead, I insist that my friends admonish anybody who describes me as "passing", "in a better place", or having "gone to Jesus". I will, however, accept, "pushing up the daises" or "worm food".
Of course, I've already made arrangements for the open bar at my wake, so perhaps I'm a little untraditional here.
The point is, if you're going to use the road, be it in a car or on a bicycle, obey the rules and use common courtesy. If you're unable to pedal hard enough to go the speed limit, get off the road and use the designated bike paths or use the side of the road, not the middle of the lane. And don't get pissed when I honk my horn at you because you're holding up traffic by being an idiot.
I completely agree with your first sentence, and disagree vigorously with the rest. Slower traffic, be it car or bike, should absolutely yield to let faster traffic pass. But cyclists are still traffic, and in places without good bike paths, the safest place to ride is often in the middle of the lane. Speed comes second to safety. At least in California, it's the law, and you see signs like this to remind impatient drivers of that.
Granted, but this was a hit-and-run. That means that after hitting him, the driver drove off to avoid having to face the consequences, probably lengthening the time it took for help to arrive. That isn't an error, it's a deliberate, selfish attempt to get himself off the hook.
Let me be clear: I'm not condoning this, I think it was terribly wrong, and I hope the hit-and-run driver is caught and does time, no matter what the explanation. As an avid cyclist who has been hit a couple of times, I take these things pretty personally.
However, we shouldn't be quick to judge the driver. People do crazy things in the heat of the moment. It's possible that the culprit is a perfectly nice person who had a moment of inattention followed by a moment of panic, and is now paralyzed with fear and remorse. The fight-or-flight reflex is a poweful one. It's also possible, of course, that the culprit is a sociopath who giggled on the way home. We don't know, and shouldn't assume.
We also should be careful with our judgements for another reason: what we hope we will do in a crisis is no guarantee of what we'll actually do. A friend of mine is doing her medical residency right now, and there's a reason that new doctors spend three years practicing in punishing conditions and under close supervision. It's because when the shit comes down you need deeply established habits to fall back on. Good character and education aren't enough. Without those habits, it's a roll of the dice.