It's not really something you can have "proof" for - you can't measure culture. It's like saying "European women are sexier".
Well, actually, people can measure culture; sociologists do it regularly. And you should also be able to measure it though proxies. For example, I was suggesting that if America's culture is more violent, there should be more violent crime. Which doesn't seem to be the case.
Of course, there are other potential explanations. Assuming that American culture is more violent, then you could explain the parity in crime rates by saying that Australians are naturally more violent, and don't need any cultural stimulus to assault people a lot.:-)
I'd start seeing what universities near you use. They won't be as big, but a large school should have circa 100k accounts and a lot of the same issues you'll face. They may already describe their infrastructure somewhere on the web. And offering to take two or three of the mail guys out to lunch or dinner will get you a ton of the nitty-gritty details and smart questions to ask yourself (and vendors).
Then once you think you have a solution, budget plenty of time for extensive testing against simulated load. Make sure you simulate failures by, e.g., pulling plugs randomly. Buy the hardware and software *after* you're 100% sure it works, not before. And where possible, roll your solution out gradually, so that small problems don't turn into MCFs.
They're probably less likely to happen - but it's got nothing to do with guns and everything to do with culture and society. [...] America is simply a violent culture.
Got any proof of that? Having lived in both places, it doesn't ring true. I felt much more at risk of being randomly assaulted by some drunk idiot in Sydney than in the major US cities I've lived in (Chicago, San Francisco). And it appears that Australia and the US have pretty similar levels of violent crime.
Re:Does anybody buy this Bullshit?
on
Pornified
·
· Score: 1
...drives the adoption of new technologies.
I'd like to know what technological breakthroughs were driven by Porn? Cameras weren't developed originally for Porn.
Do you have some sort of reading comprehension problem? The bit you quote is about adoption, not development. Is it just that it's easier to argue with things you imagine people saying, rather than what they actually said?
Your example, of an "instance", I consider not that bad... How do you phrase that better? "GAIM is already running"?
I think the long-term answer isn't in the phrasing.
My general rule when working on UI code is that if I can tell what the user probably meant, the program should just do that, rather than making them do something I consider the "right" action. If I click on my Firefox icon, for example, I get another window.
Since such errors usually happen when you have a ghost process [...]
That seems like three flaws in one. First, they wrote something that gets into states that it shouldn't be in. Then the didn't fix the problem. And once they admitted they couldn't fix the problem, they also didn't put in some sort of workaround like an automatic kill-and-restart operation.
Putting up a "Sorry, you're screwed" dialog box may be occasionally necessary. But if even a small fraction of your users see a message like that, it's at least worth a quick hack that gets them working again.
Press releases happen if someone [...] has enough money (~$300US) [...] I could do a press release about how I just bought a tube of toothpaste at the local Kroger.
I'm in for $20. Write up a page explaining how you did it and then get the whole thing covered here, and I'll Paypal you the Jackson. I'm sure you can cover your expenses.
Now, the second point might well apply to most corporations as well, but I don't think you'll find one quite as big as the USSR was.
That's true, but does it matter? Small totalitarian states don't seem to run much more efficiently than large ones.
Or are you proposing that totalitarian central planning is more efficient than capitalism at some particular size? You might persuade me for a dozen people. But Walmart has more full-time employees than a dozen US states have citizens. Perhaps we should try the Soviet Socialist Republic of Wyoming and see how they do.
This is no different than [...] I put nails all over [...] for the kid to trip on and get cut up.
Dude, wake up. Have you ever stepped on a nail? I promise, this is indeed different. Nobody will be in the emergency room over this.
Fuddruckers were jerks. He was a jerk back. He shouldn't have been a jerk, but neither should have they. And consider that he's some freak on the internet whereas they had trained professionals in meetings deciding to be jerks. I'm gonna go out on a limb here and say that perhaps we should hold the Fuddruckers people to a higher standard.
Nice way to work hurricaine Katrina into this, though. But you didn't mention the Holocaust or Nazis, so I'm only giving you a B+ for your rant.
He put content on the WWW. Fuddruckers LINKED to it. They did not do anything wrong!
They presented it as if it were their own. I'd call that wrong.
It also could be illegal. For a while people were building news sites by framing other people's articles. A round of lawsuits put an end to that.
Just because a company did it they need to reimburse someone [...]
They paid a bundle for the fancy corporate web site. They paid for the baby photo. They even paid somebody to create custom Burgertime graphics for their home page. As long as they're spending, they should offer to cough up for BurgerTime itself.
And then the guy should pass some of the dough along to the people who created the original BurgerTime so long ago.
A polite email from the company webmonkey in the first place asking if they could use the content would have been preferable.
And better still would have been them saying, "We'd like to put your game on our site. How's ten grand sound?"
I know how much money people spend on large corporate sites. If they're making somebody else's content such a big part of their site, they should cough up.
Ok, I'm going to go boldly off topic here and pass along one of the funniest things I ever heard. Remember that it was your fault.
At Burning Man there was (and probably still is) a group of people who build a Thunderdome replica and have fights. One night years ago it somehow became clown night. Clinging to the bars, you'd look around and only see painted faces and red noses.
As the clown combatants entered the arena, everybody began to chant:
two clowns enter, nine clowns leave TWO CLOWNS ENTER, NINE CLOWNS LEAVE!
There may be times where it seems like the difference between a passionate genius and a dangerous madman is thin and difficult to place. The thing is though. They really are two different things, and it matters which one that someone is.
That's a bold assertion. Have any proof?
I know smart, passionate people who are perfectly nice. As far as I'm concerned, people who can't control their aggression and desire for dominance need therapy and medication. Jobs behaves exactly like a lot of cult leaders (and some would say "other cult leaders"). I'm glad that he makes cool stuff, but he's still an asshole who makes cool stuff. It would be better if he were a good person who made cool stuff.
f you look at it objectively, a company's structure is far more similar to a dictatorship than a democracy ( which is a good thing )
Is it? It seems like one of the lessons the fall of the Soviet Union is that centrally controlled, top-down planning is much less effective than solutions mediated through marketplaces filled with independent actors. But most big corporations seem to be run like totalitarian states.
It's not that I'm advocating some sort of corporate democracy. But it's a little weird to me that so many corporate leaders seem to think that capitalism is a great thing, but only for other people.
the purpose of competing with someone is to win, not loose. crushing someone is just competing very well. there's nothing wrong with capitalism here
The purpose of capitalism is to channel various human behaviors, including the kind of aggression more appropriate to a shrieking, poop-flinging chimpanzee, into something that benefits society.
In the case of Microsoft, capitalism has failed to properly channel them. They established a monopoly and used it illegally, harming the marketplace-mediated competition that is the engine of capitalism. They are probably still trying to do that, although this time they'll surely be more subtle about it.
You could come up with a lot of ways to explain why this happened (bad regulators, high tech is different, etc) but one explanation is that Microsoft's leaders are too aggressive.
what, you think you can turn it into a lovey dovey flowers and bunnies sort of thing?
Capitalism isn't some law-of-the-jungle thing. That can be a useful metaphor to whip up the troops, but capitalism is much more like baseball or basketball. Sure, aggression is a part of it, but not unchecked aggression. There are rules to play by, and people who enforce and tune the rules to keep the game fair. It's considered bad form to shiv the opposing teams like Microsoft was convicted of doing.
I dare to say the majority of the people doing these horrible things were ALREADY EVIL one week ago, one year ago.
Oh, I agree! But once we have things locked down, I think it's worth asking when they became evil, and what we can do to reduce that from happening in the future. It's also worth asking why people around them didn't prevent this.
shooting police officers and vehicles
Well, this may be a special case in New Orleans. As a hugely corrupt and ineffective police force, I could see that people used to taking crap from them would find it hard to resist an opportunity to turn the tables. Having lived all my life in areas where cops actually protect and serve, I feel like they've earned a lot of respect. But I've never been shaken down or beaten up by a crooked cop, either.
I hope one of the good things that comes out of this is a big change in the NOPD and the New Orleans city government.
My having a gun or a knife is not a threat to any good person and not a threat to police.
Only if you can use it to maintain order. Otherwise, you and people with similar thoughts may just be a convenient gun supply source for criminals. I'd say maybe 15% of the gun owners I know are serious enough that they store them safely, practice regularly, and could use them effectively in a crisis.
And it's also hard to say what you would do once you get really hungry. Most people reading this have never gone 24 hours without food and water, let alone several days. Talking about being decent is easy with a full belly.
It's important to remember that the part of you that does the talking is relatively new brain tissue sitting on top of a big ol' lump that is millions of years older, hardwired for survival. Those who think they can easily override that should try a three-day fast. Or heck, just try holding your breath until you pass out.
How exactly are we to show compassion towards someone committing rape? [...] what justification can you give [...]
Understanding and compassion are different than justification.
Take child abuse. Most people who abuse children were themselves abused as children. I understand that being abused as a child causes life-long mental harm. I feel compassion for people with mental illness; it's a hard row to hoe. But that never justifies abusing children; that's always wrong. Even if your parents beat you like a kettle drum, that never excuses abusing others. It only explains it.
Sounds like someone needs to take a Software Engineering course. Here [amazon.com] is a book that might help with your studies.
Nice trolling! Ignoring the dialog and acting snotty is so much easier than actual discussion, isn't it?
The standard Software Engineering approach isn't wrong. If you're using traditional methods, documenting done right is better than no documentation. It fills a lot of gaps in the traditional approach. Honestly, though, many shops produce such crappy documentation that I'm not sure it's a net gain for them.
But I've tried the traditional approach and newer ones. I've done each for years. I'm much happier with the something like Extreme Programming. And it's not just me; so are my colleagues, my bosses, and my users. And the code is much better, too. If a book is telling me to try something that I've already tried and found to be worse, wouldn't you say it's time to get a new book?
Or if answering that is too hard, then you could try to go back and critique my actual points. Either one's cool by me.
Even though you may understand your function as it is written now, when you look back at your code or someone else does in the future, having the documentation of what the function does along with when and why it was created is important.
There are better ways to achieve that than documentation
If I want to know what a function does, I should be able to tell by its name and a quick look at the code. If not, some refactoring is in order. Failing that, the unit tests should tell me all I need to know.
If I want to know who created it, when they made it, and what they thought they were up to, that's what my version control system is for.
If I want to know why a particular chunk of code exists, hopefully it's obvious from the code and the unit tests. But if not, you just break the code and see what acceptance tests fail.
The only time I'll document a function is if it's part of a published API. Otherwise, the need to document a function is probably a sign of a flaw somewhere else in the process. Documentation is a poor substitute for good tests and good code.
I don't have a problem with most of these development methodologies perse, but most of them seem to lack the entire concept of DATA and INFORMATION.
You should check out things like Agile Modelling and Agile Data for more information. I don't think it's core to agile methods, as not every application uses a database. But if you're big into databases, these sites can help you see how agile approaches could work in your environment.
Do these methodologies include some prep work on gathering business requirements and understanding the underlying information relationships?
It's not just prep work; it is work that should happen all the time. That's why Refactoring and Domain-Driven Design are such a big deal to people doing Extreme Programming. We strive for representational harmony across all levels, from talking with users down to the database schema. And not just in the spec, either; as we learn more about the domain and find better representations, refactoring lets us safely change the structure of the code to match.
I remember distinctly reading on some Agile XP whatever site that CRC cards (the documentation is the code and unit tests!) are used long enough to get the devs on board with what to do AND THEN THEY ARE DISCARDED.
Yeah, people often freak out about that. I tell them, "Ok, then you can keep the cards." They will happily put them in a box and then never look at them again. Myself, I don't use CRC cards much, I just sketch UML on the whiteboard. I do tend to leave the last few months of story cards up on the wall, though.
Note that the most important documentation on an XP project is the acceptance tests, which you can think of as either machine-verifiable specs or automated versions of what QA people often do manually. Those say what the product is supposed to do. One framework for this is FIT, which uses specially structured tables in HTML documents.
Unit tests, on the other hand, are where developers say what individual chunks of the code are supposed to do.
Re:Agile is not for commercial software developmen
on
Lean Software Development
·
· Score: 5, Insightful
If you believe Agile works, you probably also believe Google can be implemented with JEEE and Oracle.
That's boldly, if unintentionally, ironic. Not only is Google hiring all the Agile developers they can find, but many agilistas have a lot of contempt for the ultra-heavyweight EJB-style approach to things.
These Agile guys really don't know what it takes to release large commercial products with million lines code, with many dependencies, many languages, requiring marketing campaigns, press tours, support training, etc.
There's no question that complicated projects have to be done differently than simple projects. But even there, you can place approaches along an agile/non-agile spectrum. You also shouldn't mistake "I don't know how" for "it's impossible".
Becoming agile also requires a fair bit of supporting infrastructure. For example, my Extreme-Programming-built code bases typically have a 1:1 production-to-test-code ratio. Bug rates for many XP projects are well under one per developer-month. Quality at that level enables fantastic agility in ways that seem impossible at typical quality levels. If you regularly have production relases with zero bugs found, weekly releases don't seem nearly as scary.
Re:Yep. Anyone who hasn't read F.P. Brooks...
on
Lean Software Development
·
· Score: 2, Informative
There's nothing fundamental in Lean, XP, or Scrum that Brooks didn't manage to say 30 years ago(yes. 30. 3-0. Thirty. Near 1/3 of a decade. check the copyright).
I don't think that's entirely true. Test-driven development, for example, seems pretty new. Hardware cost had to be pretty low before each developer could compile and run all the project tests every few minutes of development. I also don't remember Brooks talking about weekly iterations.
That's not to knock "The Mythical Man Month", by the way. I completely agree that it's required reading.
I have been dragged through numerous develop now, design later! projects, and each one of them has gone over schedule. [...] No thanks, I'd take 4 months of design and huge emails up front in exchange of 8 months corrective maintenance any day.
If that's how your agile attempts are going, you're doing it wrong. In particular, I suspect you're not writing unit tests and acceptance tests, you're not devoting sufficient time to refactoring, and I'd bet that the person making feature choices is not in the room with developers and adjusting the schedule every week.
A process like Extreme Programming isn't "develop now, design later". It's "develop now, design now". And then next week, you do it again.
The users were still bringing us new requirements for the invoicing system 2 months after it went live.
I have never seen a successful system where people don't keep bringing you new requirements. I can't name a single software product that hit 1.0 and was complete. If people are going to keep changing requirements, it seems to me that I should pick a method that is ok with that, rather than trying to force users to adjust to a method that pretends we can get everything right up front.
I agree with the above, but it is my experience that the reinforcement on developers generally needs to be in creating more documentation. The environment will naturally make all the difference. In the nasty corporate arena (my habitat), many people feel that being the only one who knows something, is their ticket to job security. As a result, they will not comment code or divulge information to anyone, etc.
Ask yourself what goals you're trying to achieve with documentation. It sounds like you care most about knowledge transfer between developers. Agile methods solve the same problems, but with different methods. Knowledge transfer, for example, are solved with practices like pair programming, collective code ownership, acceptance tests, unit tests, and putting the team in a war room.
Of course, the people steering the project can order more documentation at any time. On one recent project, we handed the code off to a team at another site. In addition to having a bit of a developer exchange program, we also took some time in the last couple of weeks to write high-level architectural docs. By doing just-in-time delivery on the docs, we saved a lot of effort keeping docs in sync with the code. And because it was scheduled as part of the regular work stream, we didn't rush; it was just another chunk of work.
Slashdot Mirror
Sorry about the bad link. Here it is.
:-)
It's not really something you can have "proof" for - you can't measure culture. It's like saying "European women are sexier".
Well, actually, people can measure culture; sociologists do it regularly. And you should also be able to measure it though proxies. For example, I was suggesting that if America's culture is more violent, there should be more violent crime. Which doesn't seem to be the case.
Of course, there are other potential explanations. Assuming that American culture is more violent, then you could explain the parity in crime rates by saying that Australians are naturally more violent, and don't need any cultural stimulus to assault people a lot.
I'd start seeing what universities near you use. They won't be as big, but a large school should have circa 100k accounts and a lot of the same issues you'll face. They may already describe their infrastructure somewhere on the web. And offering to take two or three of the mail guys out to lunch or dinner will get you a ton of the nitty-gritty details and smart questions to ask yourself (and vendors).
Then once you think you have a solution, budget plenty of time for extensive testing against simulated load. Make sure you simulate failures by, e.g., pulling plugs randomly. Buy the hardware and software *after* you're 100% sure it works, not before. And where possible, roll your solution out gradually, so that small problems don't turn into MCFs.
They're probably less likely to happen - but it's got nothing to do with guns and everything to do with culture and society. [...] America is simply a violent culture.
Got any proof of that? Having lived in both places, it doesn't ring true. I felt much more at risk of being randomly assaulted by some drunk idiot in Sydney than in the major US cities I've lived in (Chicago, San Francisco). And it appears that Australia and the US have pretty similar levels of violent crime.
Do you have some sort of reading comprehension problem? The bit you quote is about adoption, not development. Is it just that it's easier to argue with things you imagine people saying, rather than what they actually said?
Your example, of an "instance", I consider not that bad... How do you phrase that better? "GAIM is already running"?
I think the long-term answer isn't in the phrasing.
My general rule when working on UI code is that if I can tell what the user probably meant, the program should just do that, rather than making them do something I consider the "right" action. If I click on my Firefox icon, for example, I get another window.
Since such errors usually happen when you have a ghost process [...]
That seems like three flaws in one. First, they wrote something that gets into states that it shouldn't be in. Then the didn't fix the problem. And once they admitted they couldn't fix the problem, they also didn't put in some sort of workaround like an automatic kill-and-restart operation.
Putting up a "Sorry, you're screwed" dialog box may be occasionally necessary. But if even a small fraction of your users see a message like that, it's at least worth a quick hack that gets them working again.
Press releases happen if someone [...] has enough money (~$300US) [...] I could do a press release about how I just bought a tube of toothpaste at the local Kroger.
I'm in for $20. Write up a page explaining how you did it and then get the whole thing covered here, and I'll Paypal you the Jackson. I'm sure you can cover your expenses.
Now, the second point might well apply to most corporations as well, but I don't think you'll find one quite as big as the USSR was.
That's true, but does it matter? Small totalitarian states don't seem to run much more efficiently than large ones.
Or are you proposing that totalitarian central planning is more efficient than capitalism at some particular size? You might persuade me for a dozen people. But Walmart has more full-time employees than a dozen US states have citizens. Perhaps we should try the Soviet Socialist Republic of Wyoming and see how they do.
This is no different than [...] I put nails all over [...] for the kid to trip on and get cut up.
Dude, wake up. Have you ever stepped on a nail? I promise, this is indeed different. Nobody will be in the emergency room over this.
Fuddruckers were jerks. He was a jerk back. He shouldn't have been a jerk, but neither should have they. And consider that he's some freak on the internet whereas they had trained professionals in meetings deciding to be jerks. I'm gonna go out on a limb here and say that perhaps we should hold the Fuddruckers people to a higher standard.
Nice way to work hurricaine Katrina into this, though. But you didn't mention the Holocaust or Nazis, so I'm only giving you a B+ for your rant.
He put content on the WWW. Fuddruckers LINKED to it. They did not do anything wrong!
They presented it as if it were their own. I'd call that wrong.
It also could be illegal. For a while people were building news sites by framing other people's articles. A round of lawsuits put an end to that.
Just because a company did it they need to reimburse someone [...]
They paid a bundle for the fancy corporate web site. They paid for the baby photo. They even paid somebody to create custom Burgertime graphics for their home page. As long as they're spending, they should offer to cough up for BurgerTime itself.
And then the guy should pass some of the dough along to the people who created the original BurgerTime so long ago.
A polite email from the company webmonkey in the first place asking if they could use the content would have been preferable.
And better still would have been them saying, "We'd like to put your game on our site. How's ten grand sound?"
I know how much money people spend on large corporate sites. If they're making somebody else's content such a big part of their site, they should cough up.
TWO MEN ENTER, ONE MAN LEAVES!
Ok, I'm going to go boldly off topic here and pass along one of the funniest things I ever heard. Remember that it was your fault.
At Burning Man there was (and probably still is) a group of people who build a Thunderdome replica and have fights. One night years ago it somehow became clown night. Clinging to the bars, you'd look around and only see painted faces and red noses.
As the clown combatants entered the arena, everybody began to chant:
two clowns enter, nine clowns leave
TWO CLOWNS ENTER, NINE CLOWNS LEAVE!
There may be times where it seems like the difference between a passionate genius and a dangerous madman is thin and difficult to place. The thing is though. They really are two different things, and it matters which one that someone is.
That's a bold assertion. Have any proof?
I know smart, passionate people who are perfectly nice. As far as I'm concerned, people who can't control their aggression and desire for dominance need therapy and medication. Jobs behaves exactly like a lot of cult leaders (and some would say "other cult leaders"). I'm glad that he makes cool stuff, but he's still an asshole who makes cool stuff. It would be better if he were a good person who made cool stuff.
f you look at it objectively, a company's structure is far more similar to a dictatorship than a democracy ( which is a good thing )
Is it? It seems like one of the lessons the fall of the Soviet Union is that centrally controlled, top-down planning is much less effective than solutions mediated through marketplaces filled with independent actors. But most big corporations seem to be run like totalitarian states.
It's not that I'm advocating some sort of corporate democracy. But it's a little weird to me that so many corporate leaders seem to think that capitalism is a great thing, but only for other people.
the purpose of competing with someone is to win, not loose. crushing someone is just competing very well. there's nothing wrong with capitalism here
The purpose of capitalism is to channel various human behaviors, including the kind of aggression more appropriate to a shrieking, poop-flinging chimpanzee, into something that benefits society.
In the case of Microsoft, capitalism has failed to properly channel them. They established a monopoly and used it illegally, harming the marketplace-mediated competition that is the engine of capitalism. They are probably still trying to do that, although this time they'll surely be more subtle about it.
You could come up with a lot of ways to explain why this happened (bad regulators, high tech is different, etc) but one explanation is that Microsoft's leaders are too aggressive.
what, you think you can turn it into a lovey dovey flowers and bunnies sort of thing?
Capitalism isn't some law-of-the-jungle thing. That can be a useful metaphor to whip up the troops, but capitalism is much more like baseball or basketball. Sure, aggression is a part of it, but not unchecked aggression. There are rules to play by, and people who enforce and tune the rules to keep the game fair. It's considered bad form to shiv the opposing teams like Microsoft was convicted of doing.
I dare to say the majority of the people doing these horrible things were ALREADY EVIL one week ago, one year ago.
Oh, I agree! But once we have things locked down, I think it's worth asking when they became evil, and what we can do to reduce that from happening in the future. It's also worth asking why people around them didn't prevent this.
shooting police officers and vehicles
Well, this may be a special case in New Orleans. As a hugely corrupt and ineffective police force, I could see that people used to taking crap from them would find it hard to resist an opportunity to turn the tables. Having lived all my life in areas where cops actually protect and serve, I feel like they've earned a lot of respect. But I've never been shaken down or beaten up by a crooked cop, either.
I hope one of the good things that comes out of this is a big change in the NOPD and the New Orleans city government.
My having a gun or a knife is not a threat to any good person and not a threat to police.
Only if you can use it to maintain order. Otherwise, you and people with similar thoughts may just be a convenient gun supply source for criminals. I'd say maybe 15% of the gun owners I know are serious enough that they store them safely, practice regularly, and could use them effectively in a crisis.
And it's also hard to say what you would do once you get really hungry. Most people reading this have never gone 24 hours without food and water, let alone several days. Talking about being decent is easy with a full belly.
It's important to remember that the part of you that does the talking is relatively new brain tissue sitting on top of a big ol' lump that is millions of years older, hardwired for survival. Those who think they can easily override that should try a three-day fast. Or heck, just try holding your breath until you pass out.
How exactly are we to show compassion towards someone committing rape? [...] what justification can you give [...]
Understanding and compassion are different than justification.
Take child abuse. Most people who abuse children were themselves abused as children. I understand that being abused as a child causes life-long mental harm. I feel compassion for people with mental illness; it's a hard row to hoe. But that never justifies abusing children; that's always wrong. Even if your parents beat you like a kettle drum, that never excuses abusing others. It only explains it.
Sounds like someone needs to take a Software Engineering course. Here [amazon.com] is a book that might help with your studies.
Nice trolling! Ignoring the dialog and acting snotty is so much easier than actual discussion, isn't it?
The standard Software Engineering approach isn't wrong. If you're using traditional methods, documenting done right is better than no documentation. It fills a lot of gaps in the traditional approach. Honestly, though, many shops produce such crappy documentation that I'm not sure it's a net gain for them.
But I've tried the traditional approach and newer ones. I've done each for years. I'm much happier with the something like Extreme Programming. And it's not just me; so are my colleagues, my bosses, and my users. And the code is much better, too. If a book is telling me to try something that I've already tried and found to be worse, wouldn't you say it's time to get a new book?
Or if answering that is too hard, then you could try to go back and critique my actual points. Either one's cool by me.
There are better ways to achieve that than documentation
- If I want to know what a function does, I should be able to tell by its name and a quick look at the code. If not, some refactoring is in order. Failing that, the unit tests should tell me all I need to know.
- If I want to know who created it, when they made it, and what they thought they were up to, that's what my version control system is for.
- If I want to know why a particular chunk of code exists, hopefully it's obvious from the code and the unit tests. But if not, you just break the code and see what acceptance tests fail.
The only time I'll document a function is if it's part of a published API. Otherwise, the need to document a function is probably a sign of a flaw somewhere else in the process. Documentation is a poor substitute for good tests and good code.I don't have a problem with most of these development methodologies perse, but most of them seem to lack the entire concept of DATA and INFORMATION.
You should check out things like Agile Modelling and Agile Data for more information. I don't think it's core to agile methods, as not every application uses a database. But if you're big into databases, these sites can help you see how agile approaches could work in your environment.
Do these methodologies include some prep work on gathering business requirements and understanding the underlying information relationships?
It's not just prep work; it is work that should happen all the time. That's why Refactoring and Domain-Driven Design are such a big deal to people doing Extreme Programming. We strive for representational harmony across all levels, from talking with users down to the database schema. And not just in the spec, either; as we learn more about the domain and find better representations, refactoring lets us safely change the structure of the code to match.
I remember distinctly reading on some Agile XP whatever site that CRC cards (the documentation is the code and unit tests!) are used long enough to get the devs on board with what to do AND THEN THEY ARE DISCARDED.
Yeah, people often freak out about that. I tell them, "Ok, then you can keep the cards." They will happily put them in a box and then never look at them again. Myself, I don't use CRC cards much, I just sketch UML on the whiteboard. I do tend to leave the last few months of story cards up on the wall, though.
Note that the most important documentation on an XP project is the acceptance tests, which you can think of as either machine-verifiable specs or automated versions of what QA people often do manually. Those say what the product is supposed to do. One framework for this is FIT, which uses specially structured tables in HTML documents.
Unit tests, on the other hand, are where developers say what individual chunks of the code are supposed to do.
If you believe Agile works, you probably also believe Google can be implemented with JEEE and Oracle.
That's boldly, if unintentionally, ironic. Not only is Google hiring all the Agile developers they can find, but many agilistas have a lot of contempt for the ultra-heavyweight EJB-style approach to things.
These Agile guys really don't know what it takes to release large commercial products with million lines code, with many dependencies, many languages, requiring marketing campaigns, press tours, support training, etc.
There's no question that complicated projects have to be done differently than simple projects. But even there, you can place approaches along an agile/non-agile spectrum. You also shouldn't mistake "I don't know how" for "it's impossible".
Becoming agile also requires a fair bit of supporting infrastructure. For example, my Extreme-Programming-built code bases typically have a 1:1 production-to-test-code ratio. Bug rates for many XP projects are well under one per developer-month. Quality at that level enables fantastic agility in ways that seem impossible at typical quality levels. If you regularly have production relases with zero bugs found, weekly releases don't seem nearly as scary.
There's nothing fundamental in Lean, XP, or Scrum that Brooks didn't manage to say 30 years ago(yes. 30. 3-0. Thirty. Near 1/3 of a decade. check the copyright).
I don't think that's entirely true. Test-driven development, for example, seems pretty new. Hardware cost had to be pretty low before each developer could compile and run all the project tests every few minutes of development. I also don't remember Brooks talking about weekly iterations.
That's not to knock "The Mythical Man Month", by the way. I completely agree that it's required reading.
I have been dragged through numerous develop now, design later! projects, and each one of them has gone over schedule. [...] No thanks, I'd take 4 months of design and huge emails up front in exchange of 8 months corrective maintenance any day.
If that's how your agile attempts are going, you're doing it wrong. In particular, I suspect you're not writing unit tests and acceptance tests, you're not devoting sufficient time to refactoring, and I'd bet that the person making feature choices is not in the room with developers and adjusting the schedule every week.
A process like Extreme Programming isn't "develop now, design later". It's "develop now, design now". And then next week, you do it again.
The users were still bringing us new requirements for the invoicing system 2 months after it went live.
I have never seen a successful system where people don't keep bringing you new requirements. I can't name a single software product that hit 1.0 and was complete. If people are going to keep changing requirements, it seems to me that I should pick a method that is ok with that, rather than trying to force users to adjust to a method that pretends we can get everything right up front.
I agree with the above, but it is my experience that the reinforcement on developers generally needs to be in creating more documentation. The environment will naturally make all the difference. In the nasty corporate arena (my habitat), many people feel that being the only one who knows something, is their ticket to job security. As a result, they will not comment code or divulge information to anyone, etc.
Ask yourself what goals you're trying to achieve with documentation. It sounds like you care most about knowledge transfer between developers. Agile methods solve the same problems, but with different methods. Knowledge transfer, for example, are solved with practices like pair programming, collective code ownership, acceptance tests, unit tests, and putting the team in a war room.
Of course, the people steering the project can order more documentation at any time. On one recent project, we handed the code off to a team at another site. In addition to having a bit of a developer exchange program, we also took some time in the last couple of weeks to write high-level architectural docs. By doing just-in-time delivery on the docs, we saved a lot of effort keeping docs in sync with the code. And because it was scheduled as part of the regular work stream, we didn't rush; it was just another chunk of work.