So in spite of the population increasing 47% and the Gross Domestic Product increasing by 254%, co2 emissions have only increased by 24%. That's a pretty good reduction by anyone's standards.
Ah, ok, that's what he was talking about.
Of course, that's not a reduction at all. It's an increase, and a substantial one. It's not like the atmosphere is going to say, "Good work guys, you got your per-person emissions down, so I guess I'll let some of this heat out. And hey, your GDP is up, so I'll cancel one of these hurricanes, too."
And before we pat ourselves on the back too much about getting our emissions per unit of GDP down, we might ask how much of that is due to shipping most of our manufacturing to foreign countries. With a $600 billion trade defecit, a lot of the emissions we cause are actually going on somebody else's Kyoto tab.
There are countries who are largely hardly even bound by it (China)
China just recently joined the WTO, but that doesn't mean we should have waited for them. If we want to be a global leader, a good way to do it would be by leading.
and it would put our sovreignty in jeapardy. [sic]
Sorry, I missed the provision of the treaty where it said that the carbon police could annex territory or replace the president if we didn't cut emissions. Could you point that part out to me?
Besides, through our own regulation we've already cut our emissions by half since about 1972.
Based on what data? Government data says there's been a 25% rise from 1972 to 2000. And as far as I know, there are no CO2 emissions regulations in the US yet. Could you point us at them?
I don't have much time for the AC's reflexive Bush-bashing, but the picture you paint doesn't seem to be any less one-sided.
From my understanding of it, the US did pretty much disengage from the process, so although they didn't technically pull out of the treaty, they certainly have withdrawn from the process of dealing with global carbon emissions. And there's no denying that Bush welched on his campaign promise to do something about it.
And I think there's an important difference with Clinton's actions: the main post points out, we're six years further along with the science of it. The room for reasonable doubt has greadly shrunk, and we've got six more years of excess CO2 emissions to clean up now.
Thus: price and ease of installation are far more important than it actually doing what it is supposed to.
Drat. In that case, I wish ZDNet had reviewed my anti-spam solution, which is only $1 per user, and uses my patented zero-effort installer. Yep, they just send me the check, and as soon as it clears, my software automatically protects their mail servers. It couldn't be easier, and I pass 100% of the ZDNet accuracy tests.
For me, one big stress source is having more to do than I can get done. Instead, you should turn things around so that you work a fixed number of hours and always get the most important things done.
The trick is to get your bosses to accept that a your work will never be done. I prefer to handle this by keeping a to-do list that's in strict linear order of priority, hopefully ordered by the bosses. Then I make sure every week that they know how much I got done, so that they focus on that rather than how much is left to do.
It's also important to look for ways to get recurring problems to go away. For example, maybe you're doing too many password resets because of a crazed policy that demands hard-to-remember passwords changed too frequently. Or perhaps there's a way to give department secretaries the power to reset passwords with notification to you when it happens.
Part of your job is structuring your job in a way that keeps you happy over the long haul. It's really expensive to lose a good sysadmin, so for both your sake and your company's, don't let it happen.
I'm also a big fan of exercise. To minimize my stress levels, I like long, moderate cardiovascular exercise, like bike rides and fast walking. I also find yoga really helpful.
The trick for me was noticing that when I get stressed, I tend to stop exercising because I'm too busy. Now I tell myself that's bullshit; if I'm busy, the most important thing to do is to maintain my capacity for getting things done. And being relaxed and happy does wonders for my productivity.
With software, as long as it meets basic functionality and ships on time, it doesn't matter how many unpaid overtime hours or how many electrons were used.
This is true only as long as you never ship another version. That might be true for console games, but it's not generally true for software. The material that you use up is time working on future releases. Buggy code bases consume lots of it, and rewriting from scratch consumes even more.
Many of the newer code generation tools are very flexible and have some ability to preserve changes to the code; making them easier to fit into real development cycles.
The way I look at it, there's only one good kind of code generator: the kind whose output I almost never look at and never, ever tweak. Compilers, for example, are a kind of code generator that I love.
The other kind of code generator strikes me as just half implemented. Somebody has come up with some sort of interesting abstraction, but they haven't pushed it as far as a service, library, or compiler that you can use happily. These days I never use them.
What's the difference? Maintenance cost. A code generator produces a lot of code that is, pretty much by definition uninteresting. That means that you've hidden the actual interesting code in a whole mess of boring code, which makes it really expensive to maintain. And generally the generated code is highly duplicative, meaning if you want to change certain things, you have to change them in a lot of places.
To me, it seems like code generators dramatically worsen the cost-of-change curve. For any project where you aren't already planning to throw out the code, this strikes me as a mistake.
Either way, if you have solutions that don't involve redefining words, I'm genuinely interested in hearing them.
That's not particularly convincing coming after a 13-paragraph rant. Let's just leave it at this: we both agree that the way you understand it couldn't possibly work.
Everyone I know that's actually good at their job is employed and most of their companies are hiring.
Yeah, that matches my experience here. The last project I was on ended a couple of weeks ago, and we all had new jobs within two weeks. At my next gig I'll be hiring a number of people, and I'm not looking forward to it. Everybody I know is already happily employed, and finding experienced people who are reasonably sane is a challenge; I expect to see 50 resumes and do 5 interviews for each person I hire. At least.
A quick tip for those looking for jobs: the skill I can't seem to find is Test-driven development. So if you're looking for something to do with your spare time, learn that!
Ah, more XP bullshit and double-speak. [...] hey, it's not a bug. It's the client's fault, not ours.
Ok, clearly you want to be right more than you want to learn something, so I'm kinda wasting my time with you. Suffice it to say that you're raising some good issues, and that there are workable solutions to these problems. If you want to actually know what they are, drop me a line and ask. But you telling me over and over that it's impossible to do things that I have actually done isn't productive for either of us.
And again, for anything even resembling a real corporation [...] pipe dream [...] wishful thinking [...] Serious corporate development [...]
Point 1: I'm not sure if you're trying to be a condescending jerk, but that's sure how it comes across here. Before assuming that I'm only doing "quick web-site with a forum", maybe you could, say, ask. Then you'd find out that I've worked on some of the world's highest volume web sites, worked for one of the world's largest banks, and worked on financial trading software, where bugs can cost millions of dollars. I sure haven't seen it all, but I've done a little more than web guestbooks, thanks.
Point 2: I'm saying I have done this and it works. So you telling me it's impossible is unconvincing; it feels like I'm a pilot getting lectured by a flat-eatherer.
Point 3: If your organization is fundamentally too insane to figure out what software to make, then no matter what method you use you're screwed. Projects for organizations like that will be eternally late, confused, painful, and in the end, disappointing for stakeholders. So yes, I agree, agile methods may not be for you guys. That's ok; you don't have to use 'em. In fact, please don't use them, because I'd rather you blamed each other for the upcoming failures rather than blaming tools that work fine for other people just because they aren't silver bullets.
I would however keep actual releases a lot less often than weekly, and make it clear that weekly they can get at most betas and demos.
If that's all you can do every week, it's great to make that clear. Me, I can deliver working functionality every week. The trick is to slice the work so that instead of spending much of the project on invisible lower layers, I do thin slices of the app every week, cutting all the way from UI to back end.
For starters there just isn't time in a week to do any signifficant architecture changes or anything.
Well, more accurately, you don't know how to do any significant architecture changes in a week. Not knowing something how to do something doesn't mean it's impossible.
I agree that some architectural changes in large code bases or in large deployed environments can take more than a week. Those, you do gradually. But personally, I regularly do significant architecture changes in a week.
Second, I can even think of bugs which took more than a week to test.
Then A) don't write bugs, and B) automate all your tests. On the projects I do, bug rates are well below one per developer-month.
On my last project we never went home with an open bug and we always went home on time. Our total QA period before our launch was about 30 minutes because we had already automated all the tests we could think of, including unit tests, end-to-end functionality tests, and several different kinds of performance tests. And of course, any changes we made were done in pairs, meaning continuous code and design inspections. So far we've been in production for about a month with no bugs found.
This kind of thing gets at least one month of extensive QA
Yeah, if you're used to writing buggy software, that's a good attitude to have. But doing XP, you're doing QA from day one via automated acceptance tests. After N months of simultaneous QA and development, an extra month of QA generally seems unnecessary. But sure, it doesn't hurt do extra QA. I'd bet, though, that if that month-long QA periods keet turning up zero or even a small handful of defects, you'll eventually get tired of 'em and spend your QA dollars where it generates real value.
Ok, I accept that you had problems doing this. But it would be easier to have a discussion if you'd accept that I have been successful with those methods. And honest, I've done several projects like this. These methods work, both in large corporations and highly volatile startups.
You soon end up with 1 of them wanting something, 1 threatening to cancel [...] 3 playing politics [...] and 2-3 wanting to turn the whole program into something completely unrelated[...].
Having a spec often doesn't help this problem. Instead, people just pile all their requests into an incomprehensible, unworkable spec. Then, because the project is underscoped, developers end up doing whatever parts interest them.
Deciding what to build is a business problem and a political problem. Developers should give advice to the businesspeople, but they should stick to technical decisions. A planning process like the Planning Game makes sure each side does the things they are best at.
Quite insightful, but therein lies the rub: development without any specs and just doing what the clients fancy this week, basically puts _them_ in charge. [...] How do you prevent half of them from being complete idiots?
If you have a proxy for the real stakeholders, you have to close that feedback loop. For a proxy, I recommend that
they be a professional product manager
that they fairly represent the needs of all stakeholders
that you have weekly demos of progress that all stakeholders are invited to attend
that you release early and often (weekly if you can, but no less often than quarterly)
Mock-ups and small demos take a lot less work than actually coding those features
Agreed. Personally, I like whiteboards and paper. For a great reference on the topic, try Paper Prototyping by Carolyn Snyder.
Yeah, I used to work for a company that believed that. No specifications, since deciding how things will work would take too long. So we did iterative software development, instead - build it once, present it to the users, and then start over because it wasn't what they wanted.
That's a fine anecdote, and an unfortunate experience, but it's not proof that specs somehow save you from this problem. You were clearly deciding how things work when you built the code, so decisions got made. If those bad decisions were turned into a spec that you developed in one go, the product would still have sucked; it just would have taken you longer to find out that you were making sucky decisions.
The last place I was at did weekly iterations for a 4-developer, 9-month project, and it was fantastic. We had a vision of where we were going, and a rough product plan, but no written spec. Every week we built a few small features and were ready to ship at the end of it. Being able to see things working helped us kill dumb ideas sooner and, even better, let us devote more resources to things that turned out to be really important.
No development method can save you if complete idiots are in charge. But if your people have the potential to learn, shorter feedback loops help them do it sooner. So the questions I have for you are: how long were your iterations? And why didn't anything happen to improve the quality of the decisions?
I'd think that taking all of his material possessions and monetary wealth would be a pretty big punishment to a man who's made his life and living making "easy" money.
Maybe. Maybe not. He's been doing this for years, and has taken a lot of actions that show that he obviously knows what he is doing is criminal, so that may not reform him.
But there are also others to consider. Suppose your chance of getting caught while doing this is 50%. If it's a 50/50 flip between millions of dollars and probation, is that sufficient disincentive to stop others from doing this? Probably not. But if it's 50/50 between millions of dollars or a decade in prison, it's a different story.
What software are you feeding this into? A shell script with a bunch of wget's, or a real commercial piece of software?
I'm not sure I'd put commercial testing tools in the category of real software; the ones I've seen seem to be relatively lame software dressed up to appeal to corporate managers who want to believe they can buy their way out of a problem.
For my stress testing, I generally put something together out of Perl's LWP (the UserAgent module) or a custom wrapper around HttpUnit. By the time we get to load testing, this is generally pretty easy, as we use the same tools for automated acceptance testing of the app. We just rip out some interesting chunks of the acceptance tests, optimize the hell out of them, and run them on a bunch of machines.
I may also through something like Apache's ab into the mix to simulate the stateless stuff. For example, a Slashdotting consists mainly of people who show up and just look at the first page, and ab is just fine for that if you also have more sophisticated agents that represent the people who actually click on things and try out the site.
Why would a junkie, desperate for his next hit, be driving around in a vehicle, with expensive remote-RFID sensing equipment, looking for prescription drugs? Why wouldn't he just sell the laptop/van and buy the heroin he wants?
Just because the drug addicts you see are bums doesn't mean that bums are the only drug addicts.
Hey, at least its a good excuse to take a vacation to Mexico, and, oh btw, stock up on presription meds like Amoxycilin.
I'm sure the original poster knows this, but a quick warning for others:
Please don't take antibiotics unless you are under a doctor's care, and when you do make sure to take all the antibiotics prescribed. Why? Because if you do it wrongly, you can help diseases evolve antibiotic resistance. Superbugs are a big problem, causing increased costs (as people have to use expensive new antibiotics when the old ones become useless) and medical problems up to and including death (when diseases don't don't respond to the expected antibiotics).
So buy all the Xanax and Viagra you need in Mexico, but unless you have a prescription in hand or a doctor in the family, leave that Amoxycilin alone.
What bothers me about this argument is that if I'm taking prescription drugs, I now have to eat the increased cost of making sure that I'm given legitimate drugs. Sorry, but I feel that the drug distributing industry should have to be responsible for this particular service on its own.
Hi! Quick hint: drug companies get their money from people who buy medicine. No matter how you look at this, you will be paying for it. And if they'd had before a better system that prevented this fakery? You would have paid for that, too.
That's not because they're evil or mean or anything; it's just how our economic system works. You, the customer, are the only incoming source of money in the picture. You pay for the labor, the supplies, the capital, and the services they need to make the product you want. And if they go with the RFID tags, it's because they've estimated that their customers, including you, would rather pay slightly more per pill for higher confidence that the medicine is safe.
9 years in prison for what amounts to shoddy dealings. [...] Who was killed by Jeremy? Who was maimed by Jeremy? Who was raped by Jeremy?
I'm sure you think it's reasonable when a multiple murderer gets multiple sentences, right? Ok, good. Next decide what you think an appropriate sentence for stealing $40 is. Ready? Let's do some math.
The articles are lacking in hard numbers, but suppose that this guy ran his operation for a year, and that he averaged 10,000 suckers a month. That would mean 120,000 people defrauded. So 9 years would mean circa 39 minutes of time served per victim.
And that doesn't leave anything left over for the millions of people bothered by his spam, the millions of dollars in other people's resources he consumed, the time consumed in many months of tracking him down, or the harm done to the fabric of trust that makes internet commerce possible.
So no, turning him loose and saying, "Naughty naughty!" doesn't seem like appropriate punishment. Especially given that this guy was a hardcore scammer for years, one who set up more than 30 fake companies to hide his dealings.
I'm pretty damn sure that only comes from 1) Testing, and I'm not buying $10's of thousands in hardware to test with and 2) Experience, which I don't have.
Don't buy. Borrow. Most high-end hardware vendors will have some way for you to test your code on their gear, especially if that will make the difference for a big sale.
I'm leaning towards letting a consultant roll the dice, because I 'd lose my shirt if that happened.
Yes, it's a great tool for relatively static sites. For dynamic ones, I'll generally whip together something with HttpUnit or LWP so that I can simulate a user going through a dynamic, multi-step process. They do require more horsepower to generate high load, but accurate user behavior simulation gives you a lot more confidence that your app won't fall over when the hordes come.
My guess is going to be that the bottleneck is going to the the database, but we've done extensive testing with a million customer sample database running multiple instances of test applications from 10 other boxes, but that doesn't exactly prove much as it's too predictable.
Don't guess. You have too much riding on it to guess. Build proper test infrastructure. Not only will it pay off now, but it'll be hugely valuable in the future as you change and expand the application.
If you're not sure what real users will do, get some to try it out and record their activity. Then spend a little time building a load model, where you describe types of users, their activity patterns, and their expectations. (E.g.: "At the end of the month the 800 salespeople will rush to meet their quota, and during a peak hour they'll each do..." Generally I end up with nice series of spreadsheets, so I can adjust registered users and see peak hits per second come out the other end.) Then simulate the projected load and see where the real bottlenecks are.
You should be really wary about optimizing without data. As Knuth says, "Premature optimization is the root of all evil." I know a number of people who build very high volume stuff, and I don't know any of them who haven't been frequently surprised at exactly where the bottleneck turned out to be.
Also, start small and work up. There's no need to build a huge load testing suite all in one go; often you'll learn enough from the first simple tests to point developers and sysadmins in the right direction.
Of course it isnt, but in this society having a child is a choice. I should not be punished for your choice to have a child. [...] I dont give a shit that you gave yourself more work and less budget by having a kid. Thats not my problem. I'll be happy to cover for you if youve got some problems though, but I expect some consideration for it.
So you've already gone back and repaid every single person who helped your parents out when you were a kid, right? All their coworkers and friends, and everybody who paid for school for all the years you spent in it? Because otherwise that would make you a hypocritical, selfish prick, and I'd hate to think that of you.
The deal is that every kid gets that kind of help from society, and they repay it when they turn into productive citizens. And honestly, it's not a lot to ensure that society can afford to take care of you in your old age. Which, given the current low birth rates in first-world countries, is not guaranteed at all, bucko.
Simply ignoring the existance of something dangerous will not protect your children from it; either you can educate them, or society can educate them, and society doesn't have a great track record in that respect.
That's a fantastic point. I learned to shoot when I was a kid, and a lot of that learning is about how thoroughly dangerous guns are unless you approach them with the proper attitude. I haven't touched one in a decade, but even thinking about them brings back that feeling of wary respect verging on fear. It's the same feeling I get sticking my hand into the guts of a running car engine, feeding wood to a big-ass bandsaw, or working near exposed electrical wiring.
I can't imagine that kids whose only knowledge of guns came through toys and TV would be nearly as careful if they ever came across a real one.
Slashdot Mirror
So in spite of the population increasing 47% and the Gross Domestic Product increasing by 254%, co2 emissions have only increased by 24%. That's a pretty good reduction by anyone's standards.
Ah, ok, that's what he was talking about.
Of course, that's not a reduction at all. It's an increase, and a substantial one. It's not like the atmosphere is going to say, "Good work guys, you got your per-person emissions down, so I guess I'll let some of this heat out. And hey, your GDP is up, so I'll cancel one of these hurricanes, too."
And before we pat ourselves on the back too much about getting our emissions per unit of GDP down, we might ask how much of that is due to shipping most of our manufacturing to foreign countries. With a $600 billion trade defecit, a lot of the emissions we cause are actually going on somebody else's Kyoto tab.
There is no reason to sign the treaty.
Aside from impending climate change, of course.
There are countries who are largely hardly even bound by it (China)
China just recently joined the WTO, but that doesn't mean we should have waited for them. If we want to be a global leader, a good way to do it would be by leading.
and it would put our sovreignty in jeapardy. [sic]
Sorry, I missed the provision of the treaty where it said that the carbon police could annex territory or replace the president if we didn't cut emissions. Could you point that part out to me?
Besides, through our own regulation we've already cut our emissions by half since about 1972.
Based on what data? Government data says there's been a 25% rise from 1972 to 2000. And as far as I know, there are no CO2 emissions regulations in the US yet. Could you point us at them?
I don't have much time for the AC's reflexive Bush-bashing, but the picture you paint doesn't seem to be any less one-sided.
From my understanding of it, the US did pretty much disengage from the process, so although they didn't technically pull out of the treaty, they certainly have withdrawn from the process of dealing with global carbon emissions. And there's no denying that Bush welched on his campaign promise to do something about it.
And I think there's an important difference with Clinton's actions: the main post points out, we're six years further along with the science of it. The room for reasonable doubt has greadly shrunk, and we've got six more years of excess CO2 emissions to clean up now.
Thus: price and ease of installation are far more important than it actually doing what it is supposed to.
Drat. In that case, I wish ZDNet had reviewed my anti-spam solution, which is only $1 per user, and uses my patented zero-effort installer. Yep, they just send me the check, and as soon as it clears, my software automatically protects their mail servers. It couldn't be easier, and I pass 100% of the ZDNet accuracy tests.
For me, one big stress source is having more to do than I can get done. Instead, you should turn things around so that you work a fixed number of hours and always get the most important things done.
The trick is to get your bosses to accept that a your work will never be done. I prefer to handle this by keeping a to-do list that's in strict linear order of priority, hopefully ordered by the bosses. Then I make sure every week that they know how much I got done, so that they focus on that rather than how much is left to do.
It's also important to look for ways to get recurring problems to go away. For example, maybe you're doing too many password resets because of a crazed policy that demands hard-to-remember passwords changed too frequently. Or perhaps there's a way to give department secretaries the power to reset passwords with notification to you when it happens.
Part of your job is structuring your job in a way that keeps you happy over the long haul. It's really expensive to lose a good sysadmin, so for both your sake and your company's, don't let it happen.
I'm also a big fan of exercise. To minimize my stress levels, I like long, moderate cardiovascular exercise, like bike rides and fast walking. I also find yoga really helpful.
The trick for me was noticing that when I get stressed, I tend to stop exercising because I'm too busy. Now I tell myself that's bullshit; if I'm busy, the most important thing to do is to maintain my capacity for getting things done. And being relaxed and happy does wonders for my productivity.
With software, as long as it meets basic functionality and ships on time, it doesn't matter how many unpaid overtime hours or how many electrons were used.
This is true only as long as you never ship another version. That might be true for console games, but it's not generally true for software. The material that you use up is time working on future releases. Buggy code bases consume lots of it, and rewriting from scratch consumes even more.
Many of the newer code generation tools are very flexible and have some ability to preserve changes to the code; making them easier to fit into real development cycles.
The way I look at it, there's only one good kind of code generator: the kind whose output I almost never look at and never, ever tweak. Compilers, for example, are a kind of code generator that I love.
The other kind of code generator strikes me as just half implemented. Somebody has come up with some sort of interesting abstraction, but they haven't pushed it as far as a service, library, or compiler that you can use happily. These days I never use them.
What's the difference? Maintenance cost. A code generator produces a lot of code that is, pretty much by definition uninteresting. That means that you've hidden the actual interesting code in a whole mess of boring code, which makes it really expensive to maintain. And generally the generated code is highly duplicative, meaning if you want to change certain things, you have to change them in a lot of places.
To me, it seems like code generators dramatically worsen the cost-of-change curve. For any project where you aren't already planning to throw out the code, this strikes me as a mistake.
Either way, if you have solutions that don't involve redefining words, I'm genuinely interested in hearing them.
That's not particularly convincing coming after a 13-paragraph rant. Let's just leave it at this: we both agree that the way you understand it couldn't possibly work.
Everyone I know that's actually good at their job is employed and most of their companies are hiring.
Yeah, that matches my experience here. The last project I was on ended a couple of weeks ago, and we all had new jobs within two weeks. At my next gig I'll be hiring a number of people, and I'm not looking forward to it. Everybody I know is already happily employed, and finding experienced people who are reasonably sane is a challenge; I expect to see 50 resumes and do 5 interviews for each person I hire. At least.
A quick tip for those looking for jobs: the skill I can't seem to find is Test-driven development. So if you're looking for something to do with your spare time, learn that!
Ah, more XP bullshit and double-speak. [...] hey, it's not a bug. It's the client's fault, not ours.
Ok, clearly you want to be right more than you want to learn something, so I'm kinda wasting my time with you. Suffice it to say that you're raising some good issues, and that there are workable solutions to these problems. If you want to actually know what they are, drop me a line and ask. But you telling me over and over that it's impossible to do things that I have actually done isn't productive for either of us.
And again, for anything even resembling a real corporation [...] pipe dream [...] wishful thinking [...] Serious corporate development [...]
Point 1: I'm not sure if you're trying to be a condescending jerk, but that's sure how it comes across here. Before assuming that I'm only doing "quick web-site with a forum", maybe you could, say, ask. Then you'd find out that I've worked on some of the world's highest volume web sites, worked for one of the world's largest banks, and worked on financial trading software, where bugs can cost millions of dollars. I sure haven't seen it all, but I've done a little more than web guestbooks, thanks.
Point 2: I'm saying I have done this and it works. So you telling me it's impossible is unconvincing; it feels like I'm a pilot getting lectured by a flat-eatherer.
Point 3: If your organization is fundamentally too insane to figure out what software to make, then no matter what method you use you're screwed. Projects for organizations like that will be eternally late, confused, painful, and in the end, disappointing for stakeholders. So yes, I agree, agile methods may not be for you guys. That's ok; you don't have to use 'em. In fact, please don't use them, because I'd rather you blamed each other for the upcoming failures rather than blaming tools that work fine for other people just because they aren't silver bullets.
I would however keep actual releases a lot less often than weekly, and make it clear that weekly they can get at most betas and demos.
If that's all you can do every week, it's great to make that clear. Me, I can deliver working functionality every week. The trick is to slice the work so that instead of spending much of the project on invisible lower layers, I do thin slices of the app every week, cutting all the way from UI to back end.
For starters there just isn't time in a week to do any signifficant architecture changes or anything.
Well, more accurately, you don't know how to do any significant architecture changes in a week. Not knowing something how to do something doesn't mean it's impossible.
I agree that some architectural changes in large code bases or in large deployed environments can take more than a week. Those, you do gradually. But personally, I regularly do significant architecture changes in a week.
Second, I can even think of bugs which took more than a week to test.
Then A) don't write bugs, and B) automate all your tests. On the projects I do, bug rates are well below one per developer-month.
On my last project we never went home with an open bug and we always went home on time. Our total QA period before our launch was about 30 minutes because we had already automated all the tests we could think of, including unit tests, end-to-end functionality tests, and several different kinds of performance tests. And of course, any changes we made were done in pairs, meaning continuous code and design inspections. So far we've been in production for about a month with no bugs found.
This kind of thing gets at least one month of extensive QA
Yeah, if you're used to writing buggy software, that's a good attitude to have. But doing XP, you're doing QA from day one via automated acceptance tests. After N months of simultaneous QA and development, an extra month of QA generally seems unnecessary. But sure, it doesn't hurt do extra QA. I'd bet, though, that if that month-long QA periods keet turning up zero or even a small handful of defects, you'll eventually get tired of 'em and spend your QA dollars where it generates real value.
Ok, I accept that you had problems doing this. But it would be easier to have a discussion if you'd accept that I have been successful with those methods. And honest, I've done several projects like this. These methods work, both in large corporations and highly volatile startups.
You soon end up with 1 of them wanting something, 1 threatening to cancel [...] 3 playing politics [...] and 2-3 wanting to turn the whole program into something completely unrelated[...].
Having a spec often doesn't help this problem. Instead, people just pile all their requests into an incomprehensible, unworkable spec. Then, because the project is underscoped, developers end up doing whatever parts interest them.
Deciding what to build is a business problem and a political problem. Developers should give advice to the businesspeople, but they should stick to technical decisions. A planning process like the Planning Game makes sure each side does the things they are best at.
Quite insightful, but therein lies the rub: development without any specs and just doing what the clients fancy this week, basically puts _them_ in charge. [...] How do you prevent half of them from being complete idiots?
If you have a proxy for the real stakeholders, you have to close that feedback loop. For a proxy, I recommend that
- they be a professional product manager
- that they fairly represent the needs of all stakeholders
- that you have weekly demos of progress that all stakeholders are invited to attend
- that you release early and often (weekly if you can, but no less often than quarterly)
Mock-ups and small demos take a lot less work than actually coding those featuresAgreed. Personally, I like whiteboards and paper. For a great reference on the topic, try Paper Prototyping by Carolyn Snyder.
Yeah, I used to work for a company that believed that. No specifications, since deciding how things will work would take too long. So we did iterative software development, instead - build it once, present it to the users, and then start over because it wasn't what they wanted.
That's a fine anecdote, and an unfortunate experience, but it's not proof that specs somehow save you from this problem. You were clearly deciding how things work when you built the code, so decisions got made. If those bad decisions were turned into a spec that you developed in one go, the product would still have sucked; it just would have taken you longer to find out that you were making sucky decisions.
The last place I was at did weekly iterations for a 4-developer, 9-month project, and it was fantastic. We had a vision of where we were going, and a rough product plan, but no written spec. Every week we built a few small features and were ready to ship at the end of it. Being able to see things working helped us kill dumb ideas sooner and, even better, let us devote more resources to things that turned out to be really important.
No development method can save you if complete idiots are in charge. But if your people have the potential to learn, shorter feedback loops help them do it sooner. So the questions I have for you are: how long were your iterations? And why didn't anything happen to improve the quality of the decisions?
I'd think that taking all of his material possessions and monetary wealth would be a pretty big punishment to a man who's made his life and living making "easy" money.
Maybe. Maybe not. He's been doing this for years, and has taken a lot of actions that show that he obviously knows what he is doing is criminal, so that may not reform him.
But there are also others to consider. Suppose your chance of getting caught while doing this is 50%. If it's a 50/50 flip between millions of dollars and probation, is that sufficient disincentive to stop others from doing this? Probably not. But if it's 50/50 between millions of dollars or a decade in prison, it's a different story.
What software are you feeding this into? A shell script with a bunch of wget's, or a real commercial piece of software?
I'm not sure I'd put commercial testing tools in the category of real software; the ones I've seen seem to be relatively lame software dressed up to appeal to corporate managers who want to believe they can buy their way out of a problem.
For my stress testing, I generally put something together out of Perl's LWP (the UserAgent module) or a custom wrapper around HttpUnit. By the time we get to load testing, this is generally pretty easy, as we use the same tools for automated acceptance testing of the app. We just rip out some interesting chunks of the acceptance tests, optimize the hell out of them, and run them on a bunch of machines.
I may also through something like Apache's ab into the mix to simulate the stateless stuff. For example, a Slashdotting consists mainly of people who show up and just look at the first page, and ab is just fine for that if you also have more sophisticated agents that represent the people who actually click on things and try out the site.
Why would a junkie, desperate for his next hit, be driving around in a vehicle, with expensive remote-RFID sensing equipment, looking for prescription drugs? Why wouldn't he just sell the laptop/van and buy the heroin he wants?
Just because the drug addicts you see are bums doesn't mean that bums are the only drug addicts.
Hey, at least its a good excuse to take a vacation to Mexico, and, oh btw, stock up on presription meds like Amoxycilin.
I'm sure the original poster knows this, but a quick warning for others:
Please don't take antibiotics unless you are under a doctor's care, and when you do make sure to take all the antibiotics prescribed. Why? Because if you do it wrongly, you can help diseases evolve antibiotic resistance. Superbugs are a big problem, causing increased costs (as people have to use expensive new antibiotics when the old ones become useless) and medical problems up to and including death (when diseases don't don't respond to the expected antibiotics).
So buy all the Xanax and Viagra you need in Mexico, but unless you have a prescription in hand or a doctor in the family, leave that Amoxycilin alone.
What bothers me about this argument is that if I'm taking prescription drugs, I now have to eat the increased cost of making sure that I'm given legitimate drugs. Sorry, but I feel that the drug distributing industry should have to be responsible for this particular service on its own.
Hi! Quick hint: drug companies get their money from people who buy medicine. No matter how you look at this, you will be paying for it. And if they'd had before a better system that prevented this fakery? You would have paid for that, too.
That's not because they're evil or mean or anything; it's just how our economic system works. You, the customer, are the only incoming source of money in the picture. You pay for the labor, the supplies, the capital, and the services they need to make the product you want. And if they go with the RFID tags, it's because they've estimated that their customers, including you, would rather pay slightly more per pill for higher confidence that the medicine is safe.
9 years in prison for what amounts to shoddy dealings. [...] Who was killed by Jeremy? Who was maimed by Jeremy? Who was raped by Jeremy?
I'm sure you think it's reasonable when a multiple murderer gets multiple sentences, right? Ok, good. Next decide what you think an appropriate sentence for stealing $40 is. Ready? Let's do some math.
The articles are lacking in hard numbers, but suppose that this guy ran his operation for a year, and that he averaged 10,000 suckers a month. That would mean 120,000 people defrauded. So 9 years would mean circa 39 minutes of time served per victim.
And that doesn't leave anything left over for the millions of people bothered by his spam, the millions of dollars in other people's resources he consumed, the time consumed in many months of tracking him down, or the harm done to the fabric of trust that makes internet commerce possible.
So no, turning him loose and saying, "Naughty naughty!" doesn't seem like appropriate punishment. Especially given that this guy was a hardcore scammer for years, one who set up more than 30 fake companies to hide his dealings.
I'm pretty damn sure that only comes from 1) Testing, and I'm not buying $10's of thousands in hardware to test with and 2) Experience, which I don't have.
Don't buy. Borrow. Most high-end hardware vendors will have some way for you to test your code on their gear, especially if that will make the difference for a big sale.
I'm leaning towards letting a consultant roll the dice, because I 'd lose my shirt if that happened.
That's a very reasonable option.
Yes, it's a great tool for relatively static sites. For dynamic ones, I'll generally whip together something with HttpUnit or LWP so that I can simulate a user going through a dynamic, multi-step process. They do require more horsepower to generate high load, but accurate user behavior simulation gives you a lot more confidence that your app won't fall over when the hordes come.
My guess is going to be that the bottleneck is going to the the database, but we've done extensive testing with a million customer sample database running multiple instances of test applications from 10 other boxes, but that doesn't exactly prove much as it's too predictable.
Don't guess. You have too much riding on it to guess. Build proper test infrastructure. Not only will it pay off now, but it'll be hugely valuable in the future as you change and expand the application.
If you're not sure what real users will do, get some to try it out and record their activity. Then spend a little time building a load model, where you describe types of users, their activity patterns, and their expectations. (E.g.: "At the end of the month the 800 salespeople will rush to meet their quota, and during a peak hour they'll each do..." Generally I end up with nice series of spreadsheets, so I can adjust registered users and see peak hits per second come out the other end.) Then simulate the projected load and see where the real bottlenecks are.
You should be really wary about optimizing without data. As Knuth says, "Premature optimization is the root of all evil." I know a number of people who build very high volume stuff, and I don't know any of them who haven't been frequently surprised at exactly where the bottleneck turned out to be.
Also, start small and work up. There's no need to build a huge load testing suite all in one go; often you'll learn enough from the first simple tests to point developers and sysadmins in the right direction.
Of course it isnt, but in this society having a child is a choice. I should not be punished for your choice to have a child. [...] I dont give a shit that you gave yourself more work and less budget by having a kid. Thats not my problem. I'll be happy to cover for you if youve got some problems though, but I expect some consideration for it.
So you've already gone back and repaid every single person who helped your parents out when you were a kid, right? All their coworkers and friends, and everybody who paid for school for all the years you spent in it? Because otherwise that would make you a hypocritical, selfish prick, and I'd hate to think that of you.
The deal is that every kid gets that kind of help from society, and they repay it when they turn into productive citizens. And honestly, it's not a lot to ensure that society can afford to take care of you in your old age. Which, given the current low birth rates in first-world countries, is not guaranteed at all, bucko.
Simply ignoring the existance of something dangerous will not protect your children from it; either you can educate them, or society can educate them, and society doesn't have a great track record in that respect.
That's a fantastic point. I learned to shoot when I was a kid, and a lot of that learning is about how thoroughly dangerous guns are unless you approach them with the proper attitude. I haven't touched one in a decade, but even thinking about them brings back that feeling of wary respect verging on fear. It's the same feeling I get sticking my hand into the guts of a running car engine, feeding wood to a big-ass bandsaw, or working near exposed electrical wiring.
I can't imagine that kids whose only knowledge of guns came through toys and TV would be nearly as careful if they ever came across a real one.