They also field-tested this at Mardi Gras this year in New Orleans. Unfortunately, the crowds mistook it for a personal lubricant and 47 people ended up hospitalized for exhaustion.
I live in Hong Kong and because of them I can¦t get e-mail through to some of my family and friends. Now I¦m a decent person, I post to/. send in bug reports for open-source software and I¦ve never spammed anyone in my life but I still have to suffer these restrictions.
I'm a decent person, but for years I've lived in bad neighborhoods. Many of my friends aren't comfortable visiting me. Is that unfair? Or just reasonable behavior?
Regardless, my whining doesn't make them come visit me more often. So a few years back I moved to a slightly better area and I do what I can to make my new 'hood safer still. Perhaps you could try that? Given your location and your language skills, you could be a big help to the anti-spam community.
I hope that China does something about spam mail but this really is not the way to encourage it.
That's a nice thought, but utterly wrong. Something like this is the only way to encourage it. Chinese spammers have been a problem for quite a while, but a gazillion complaints had as much effect as the chirping of sparrows. It's only widespread blocking that has made the government sit up and take notice.
It's sad that it had to come to this, but the only lesson to learn is that ignoring spam doesn't make anything better; the longer you wait, the more painful it is to clean up.
Uh, I read the first amendment like this: "Congress shall make no law [...] [making it possible for anyone to abridge someone else's] freedom of speech, or the press [...]"
Wow! This style of inserting whole phrases at random points into the Bill of Rights could open up whole new avenues for the Supreme Court:
Congress shall make no law [making it possible for anyone to] respect an establishment of religion
Yep! The constitution doesn't just protect us from a state religion; it actually mandates blasphemy!
If a law enables companies to suppress free speech by allowing those companies to file SLAPP lawsuits, isn't that a law abridging the freedom of speech, even if only indirectly?
In a word? No. It's just an egregious misuse of the legal system. If the government were using or paying corporations to sue individuals because of their political beliefs or actions, then you'd have a First Amendment issue.
Re:XML::Comma -- a perl-based framwork
on
Zope or Cocoon 2?
·
· Score: 2
But in lots of web-systems-development contexts the emphasis is on getting new sets of features built as quickly as possible, and there's a strong pressure to be in "permanent protyping" mode.
Prototyping is where you intentionally ignore a lot of the factors important in the real world, so that you can quickly bring some desired aspect to apparent completion. A great example is building a movie set: you only build the walls and finish the surfaces that the camera sees, but the sink doesn't have plumbing and there's no glass in the windows.
On a project of any size, the notion of "permanent prototyping" is a dangerous myth. If you're building for long-term quality and flexibility, you can't cut corners; they always come back to bite you. Trying to turn a movie set into a real house is much more painful than just building a real house, especially if there are people living in it already.
A better solution is to pick one of the various agile methodologies, like Extreme Programming, Feature-Driven Development, or Scrum. All of these methods focus on building very high quality software in a way that's amenable to change.
XP, for example, lets the biz folks change the spec every week or two if they want. (Which sounds like disaster, but smart people quickly realize that making random turns every few blocks is not the best way to get somewhere.) That gives you all the benefits of "permanent prototyping" without getting it's biggest drawback: the speed with which you reach critial mass.
You're certainly right that expert programmers don't absolutely need static typing. But for experts, static typing isn't that much of a burden, and even us geniuses have those occasional Friday afternoons where our brains go to the bar two hours before our bodies.
And how hard is it, really, to delete 15 messages you don't want?
This "just delete it" argument was intriguing and innovative as recently as 1994. Except then you would have said "1 message" out of 30 rather than "15 messages".
So when does it become ok to take action? When your mail is 80% spam? 90% spam? 99% spam? Those numbers sound ridiculous now, but 50% sounded ridiculous just a couple of years back.
Honestly, what percentage of Internet users do you suspect get hundreds of spam-mails weekly? I'd bet it's very few.
For now. My spam count is monotonically increasing, and it has been for a decade, allowing me to reach that lofty level.
There's no reason to think that it won't get like this for everybody unless we take action. Spamming is practially free, especially when you steal the resources needed for it. And for someone already selling scams and garbage, I imagine theft of resources is not a big worry.
My personal favorite is a simple analog watch that goes the wrong way 'round. It's Lorus Goofy watch.; Goofy's in the center, surrounded by the numbers laid out counterclockwise. My favorite trick: When somebody at a bar asks me the time I just hold my wrist up to them. They look at it for a while and conclude that it's time to go home.
Also, please realize that object-oriented programming, multiple inheritance, garbage collection, and operator/function overloading are all very powerful language features that require careful design and consideration to use correctly. There are times when each of these is a massive help to the programmer, and there are other times when they can each create intractable messes.
And worse, developers who are learning the language as they go will try to use all the cool features all over the place, making an unmaintainable mess.
If your developers only know COBOL, you'd be much better off sticking with that then turning a bunch of COBOL developers loose with C++ or Perl. And if your developers already know, say, Java, then making them switch to C++ just to get multiple inheritance is boneheaded.
The original poster's team should stick with what they know. Or if they are looking to make a switch, they should spend three months on a scratch project. One way or another they're going to have to learn they new language well, and a production system is a dumb place to practice.
Any time you need to write software that does what you tell it to do instead of it doing what it wants to do (GC in the background for instance), high-level languages just don't cut it.
This is certainly true, but just doesn't matter for most people. Sure, I can write in assembler or C and have exact control over everything, squeezing out every last byte and CPU cycle But for a large amount of commercial development, it just doesn't matter.
Moore's Law makes hardware better all the time, but programmers aren't getting any smarter. Even if you're getting paid minimum wage, saving a day tracking down memory allocation issues will pay for the CPU time that a GC eats.
The whole point of computers is to take care of the things that machines are good at, leaving the fun stuff for us. And I dunno about you, but it's been a long time since I enjoyed figuring out the (hopefully) one place in 100,000 lines of code I'd forgotten to balance my malloc's and my frees.
That's true about most code, but most code is crappy. As Martin Fowler says, "Any fool can write code that a computer can understand; good programmers write code that humans can understand."
A while ago I did a comparative study of the graphical design tools on which UML is based. My conclusion was that the idea was a pretty bad one and all of them became more trouble than they were worth as they attempted to track every feature of C++ or such graphically. As the projects grew in scope the diagrams became less and less useful.
Amen. Diagrams, like any other documentation, should be carefully abstracted summaries of the code, not 1:1 duplication of it. 99% of the UML I do is on a white board or on scratch paper, which is where it belongs.
I love, love, love VMWare for this. It's ctrl-Z for sysadmins.
Lately I wanted to experiment with the various kernel-level security packages like LOMAC, LIDS, and SELinux. It was great to be able to build a default linux install on a virtual disk and then copy it three or four times to install the weird security stuff.
It's even better for non-Unix OSes. A friend wanted help installing his Java web app on NT. I built a variety of virtual machines for testing, all using the VMWare "Undoable disk" choice. So when some weird registry key got screwed up by an Oracle installer, I just picked "Undo" and tried again!
If you have to use crappy OS or packages that are inclined to break things and put crap everywhere, VMWare is a delight!
Yeah, in a "theoretical sense". Please tell me what is the hypothetical ethical thing to do when a presumably "democratic" system is actually entirely corrupt to the point that you *cannot peacefully effect any change in the direction you want*. Hmmm? According to you one enters the realm of "terrorist".
Your implication that the US government is entirely corrupt suggests you haven't lived any place outside the US, certainly not in any third-world country.
Here a president can't even get a blow job without a near miss at impeachment. And a year ago if you'd asked anybody to name one of the shadowy corporate moguls for whom Bush would be a sock puppet, anybody in California would have said "Kennie Lay of Enron". Now he's looking at a two-year-long colonoscopy by Congress and the press. And hopefully, jail time.
So "entirely corrupt" is way over the line. "Entirely corrupt" is when 30% of the government budget ends up in the pocket of the president and cabinet members. (Hello, Nigeria!) "Entirely corrupt" is when if you open your mouth you disappear in the middle of the night and they drop your body from a plane fifty miles out to sea. (Hello, Chile!)
Our ability to affect our government is far from theoretical. If you want to have more than 1/275,000,000 of the power, you can get it. Go get a master's in public policy from a top-notch school, go to Washington, and work your ass off. I know people who are doing it, and you can be one of them. Or if policy isn't to your tastes, go out and make a few million dollars and then fund people working on something that matters. There are always smart people looking for funding to change the world.
Maybe it isn't the case with you personally, but here in San Francisco 99% of the people who are bitching about how powerless they are don't do anything but bitch. If you wanna see this country move in your direction, you can't just ride along and yammer; you gotta hop off, roll up your sleeves, and push for all you're worth.
[...] you probably have $60 bucks somewhere. Just send them the money, [...]
Man, I tried that. I called them up a number of months back and said, "I already downloaded the latest version, and I don't need a box of manuals to throw out. Can I just give you the money?" It was impossible for normal sales reps to do that, but she kept promising to get in touch with her boss's boss, who could do it. I probably called the rep back five or six times before I gave up.
I know this is America, land of the fee, but you think it would be easier to give money away.
So I'm glad they're offering this; I'm gonna sign up so that they get my dough.
If it's a bug, it's not a big one. The worst case is that you get 4 * +1 to 5 and then you get 4 "overrated" scores, reducing your karma to 46. But if this happens to you again, you just end up back at 46. And the worst case is unlikely; more than likely 48 is the lowest this problem will ever take you.
Think of it as a karma cap of 45 with some room to take care of duelling moderator issues and you'll be fine with it.
I've used mod_gzip for the last year or so on a number of sites, one of which gets millions of hits a day. Trading idle CPU time in for drastically reduced bandwidth is a sweet bargain indeed. As a side benefit, those on slow links get a much faster experience.
One could make the same argument about any etiquette. And in some cases, like proper pinky placement while tea-sipping, the etiquette really is a niche, because the etiquette goes with something that is itself a niche. But that's not the case with email, which is rapidly becoming universal.
Any reasonable etiquette standard, from editing your email to not using your cellphone during a movie to not slurping your soup, is about consideration for others, about trading a little effort on your part for some benefit to those you deal with. To develop a taste for manners, all you need is the chance to regularly experience both sides of the behavior. A daily shower seems like an unnecessary nuisance until you sit next to somebody who bathes monthly.
Ever since the September that never ended, the Internet has been flooded with relative newbies. Newbies anywhere are notoriously short on manners. But the percentage of new people on the Internet has probably peaked already, so we should soon see some collective progress.
Certainly, I've seen signs of it. I've stopped receiving "send a card to tumorous Timmy" forward hoaxes; all my correspondents have passed that stage. And I've seen progress in the real world, too; during the last three movies I've attended, I haven't had to kill a single person for cellphone use.
And so it will go with quoting. A well-formatted message is more pleasant to read and easier to understand; those who want to communicate well will take the extra time. And those who don't catch on will look like dolts.
Like you, I sketch things out as I'm designing them, and then toss the diagrams when I'm done. But mainly, I use UML for communicating with people. When discussing design questions, it's great to be able to go to a whiteboard and sketch things as you talk about them.
People are much more likely to understand something when you communicate it via multiple modes, so description plus diagram is much better than either one on its own. And using UML rather than some home-grown notation makes it easier to communicate, as you don't have the questions of "What does that arrow mean again?"
.
Sure, this is "back-of-envelope" stuff, but just because you erase the diagrams doesn't mean they aren't valuable! The hard part about building software isn't the coding; it's the thinking about what to code.
I grant that for many Ask Slashdot questions, they would have been better off going to Google. But for things like this, you're missing the point.
He's not asking what exists, he's asking what people use and recommend. Most of the information that Google comes up with is marketing drivel. And even the personal opinions out there may not be helpful to us geeks: Slashdot readers are likely to be much more fussy about high-tech tools like this.
But the users don't want to write reports - they have other things to do.
Agreed! But if they can do it themselves in a few minutes or spend a few hours waiting for you to become available, most of them will do it themselves. Note the rise of Wal-Mart; people say they want service even if it costs a little more, but most of them really prefer cheap self-service.
I'm not saying you can automate everything away and just have them mail you your check. But in my experience, about 80% of what people want from reports is very similar. Giving them the power to do that easily (via, say, simple web-based report generators and data browsers) lets you devote your attention to the 20% of your report-writing that's actually interesting.
Report writing is my job.
Nope! Your job is to help people to get the information they need to do their jobs better.
Your boss may think your title is Senior Report Writer, but there's no need to confuse him by telling him the truth. By focusing on the need rather than a particular solution, you can have more fun and give the business more value for their money.
The path of "get a complete spec" can certainly work, but I find it awfully painful. For projects that are both novel and non-trivial, forcing the discovery of every detail up front can raise the total cost of the project significantly.
And then once you're working from a fixed spec, you have endless battles about whether request X is a feature (and therefore chargeable) or a bug fix (and therefore free). And all the energy spent on defending the spec from change and then negotiating the inevitable changes is energy I'd rather put into coding.
Personally, I prefer approaches like evolutionary delivery or Extreme Programming. The client gets to change their mind as much as they want as long as they're willing to pay the cost of changes. I find this makes them more thoughtful about the changes they want. Since they are getting working versions on a regular basis, they're much more mellow.
And generally the way we accomplish something in impossible times is to cut corners. Sure, it works in three weeks, but the code is snarled, there is no documentation, and you took advantage of a security hole to make it go.
Now of course you tell the manager, "If I spend three weeks on a temporary hack, I'm still going to have to spend another twelve weeks later doing it right."
And they say, "Sure! As soon as this crisis is past."
Of course, as soon as crisis A is done, crisis B is looming. And after B, then C, D, and E. So a lot of 'temporary' code gets written. Eventually, the project is just a big heap of steaming turds with some pretty contact paper covering most of the surface. And then the good programmers catch on and leave; the bad ones spend the rest of the lives sticking on more contact paper.
And the manager, of course, has long since moved on; he met his deadlines, after all, so he must be a good manager. And the person who's now in charge of that group? Well he must be a bad manager, because his team has lots of bugs and never makes deadlines anymore.
In my experience, most people turn up with both a rough list of features and a rough target date. It is very rare that they will want 100% of the features without regards to the date; instead, people are willing to cut features to bring things in on a schedule that suits them.
people producing the estimates aren't the people doing the actual work.
Absolutely true. Not only are the people doing the work more likely to give good estimates, but people also work much harder to meet their own estimates rather than somebody else's numbers.
estimate the amount of time it will take...then reduce that by 20%
Absolutely false. This is the worst thing you can do for morale. The programmers will know they are working to bullshit targets. And then when they miss the fake deadlines, they'll be stressed and grumpy for the last 20% of the work, meaning you'll get that last part slower and with poorer quality then you otherwise would have.
Slashdot Mirror
They also field-tested this at Mardi Gras this year in New Orleans. Unfortunately, the crowds mistook it for a personal lubricant and 47 people ended up hospitalized for exhaustion.
I live in Hong Kong and because of them I can¦t get e-mail through to some of my family and friends. Now I¦m a decent person, I post to /. send in bug reports for open-source software and I¦ve never spammed anyone in my life but I still have to suffer these restrictions.
I'm a decent person, but for years I've lived in bad neighborhoods. Many of my friends aren't comfortable visiting me. Is that unfair? Or just reasonable behavior?
Regardless, my whining doesn't make them come visit me more often. So a few years back I moved to a slightly better area and I do what I can to make my new 'hood safer still. Perhaps you could try that? Given your location and your language skills, you could be a big help to the anti-spam community.
I hope that China does something about spam mail but this really is not the way to encourage it.
That's a nice thought, but utterly wrong. Something like this is the only way to encourage it. Chinese spammers have been a problem for quite a while, but a gazillion complaints had as much effect as the chirping of sparrows. It's only widespread blocking that has made the government sit up and take notice.
It's sad that it had to come to this, but the only lesson to learn is that ignoring spam doesn't make anything better; the longer you wait, the more painful it is to clean up.
Uh, I read the first amendment like this: "Congress shall make no law [...] [making it possible for anyone to abridge someone else's] freedom of speech, or the press [...]"
Wow! This style of inserting whole phrases at random points into the Bill of Rights could open up whole new avenues for the Supreme Court:
Yep! The constitution doesn't just protect us from a state religion; it actually mandates blasphemy!If a law enables companies to suppress free speech by allowing those companies to file SLAPP lawsuits, isn't that a law abridging the freedom of speech, even if only indirectly?
In a word? No. It's just an egregious misuse of the legal system. If the government were using or paying corporations to sue individuals because of their political beliefs or actions, then you'd have a First Amendment issue.
But in lots of web-systems-development contexts the emphasis is on getting new sets of features built as quickly as possible, and there's a strong pressure to be in "permanent protyping" mode.
Prototyping is where you intentionally ignore a lot of the factors important in the real world, so that you can quickly bring some desired aspect to apparent completion. A great example is building a movie set: you only build the walls and finish the surfaces that the camera sees, but the sink doesn't have plumbing and there's no glass in the windows.
On a project of any size, the notion of "permanent prototyping" is a dangerous myth. If you're building for long-term quality and flexibility, you can't cut corners; they always come back to bite you. Trying to turn a movie set into a real house is much more painful than just building a real house, especially if there are people living in it already.
A better solution is to pick one of the various agile methodologies, like Extreme Programming, Feature-Driven Development, or Scrum. All of these methods focus on building very high quality software in a way that's amenable to change.
XP, for example, lets the biz folks change the spec every week or two if they want. (Which sounds like disaster, but smart people quickly realize that making random turns every few blocks is not the best way to get somewhere.) That gives you all the benefits of "permanent prototyping" without getting it's biggest drawback: the speed with which you reach critial mass.
You're certainly right that expert programmers don't absolutely need static typing. But for experts, static typing isn't that much of a burden, and even us geniuses have those occasional Friday afternoons where our brains go to the bar two hours before our bodies.
And how hard is it, really, to delete 15 messages you don't want?
This "just delete it" argument was intriguing and innovative as recently as 1994. Except then you would have said "1 message" out of 30 rather than "15 messages".
So when does it become ok to take action? When your mail is 80% spam? 90% spam? 99% spam? Those numbers sound ridiculous now, but 50% sounded ridiculous just a couple of years back.
Honestly, what percentage of Internet users do you suspect get hundreds of spam-mails weekly? I'd bet it's very few.
For now. My spam count is monotonically increasing, and it has been for a decade, allowing me to reach that lofty level.
There's no reason to think that it won't get like this for everybody unless we take action. Spamming is practially free, especially when you steal the resources needed for it. And for someone already selling scams and garbage, I imagine theft of resources is not a big worry.
My personal favorite is a simple analog watch that goes the wrong way 'round. It's Lorus Goofy watch.; Goofy's in the center, surrounded by the numbers laid out counterclockwise. My favorite trick: When somebody at a bar asks me the time I just hold my wrist up to them. They look at it for a while and conclude that it's time to go home.
Also, please realize that object-oriented programming, multiple inheritance, garbage collection, and operator/function overloading are all very powerful language features that require careful design and consideration to use correctly. There are times when each of these is a massive help to the programmer, and there are other times when they can each create intractable messes.
And worse, developers who are learning the language as they go will try to use all the cool features all over the place, making an unmaintainable mess.
If your developers only know COBOL, you'd be much better off sticking with that then turning a bunch of COBOL developers loose with C++ or Perl. And if your developers already know, say, Java, then making them switch to C++ just to get multiple inheritance is boneheaded.
The original poster's team should stick with what they know. Or if they are looking to make a switch, they should spend three months on a scratch project. One way or another they're going to have to learn they new language well, and a production system is a dumb place to practice.
Any time you need to write software that does what you tell it to do instead of it doing what it wants to do (GC in the background for instance), high-level languages just don't cut it.
This is certainly true, but just doesn't matter for most people. Sure, I can write in assembler or C and have exact control over everything, squeezing out every last byte and CPU cycle But for a large amount of commercial development, it just doesn't matter.
Moore's Law makes hardware better all the time, but programmers aren't getting any smarter. Even if you're getting paid minimum wage, saving a day tracking down memory allocation issues will pay for the CPU time that a GC eats.
The whole point of computers is to take care of the things that machines are good at, leaving the fun stuff for us. And I dunno about you, but it's been a long time since I enjoyed figuring out the (hopefully) one place in 100,000 lines of code I'd forgotten to balance my malloc's and my frees.
Code in general writes easier than it reads.
That's true about most code, but most code is crappy. As Martin Fowler says, "Any fool can write code that a computer can understand; good programmers write code that humans can understand."
A while ago I did a comparative study of the graphical design tools on which UML is based. My conclusion was that the idea was a pretty bad one and all of them became more trouble than they were worth as they attempted to track every feature of C++ or such graphically. As the projects grew in scope the diagrams became less and less useful.
Amen. Diagrams, like any other documentation, should be carefully abstracted summaries of the code, not 1:1 duplication of it. 99% of the UML I do is on a white board or on scratch paper, which is where it belongs.
I love, love, love VMWare for this. It's ctrl-Z for sysadmins.
Lately I wanted to experiment with the various kernel-level security packages like LOMAC, LIDS, and SELinux. It was great to be able to build a default linux install on a virtual disk and then copy it three or four times to install the weird security stuff.
It's even better for non-Unix OSes. A friend wanted help installing his Java web app on NT. I built a variety of virtual machines for testing, all using the VMWare "Undoable disk" choice. So when some weird registry key got screwed up by an Oracle installer, I just picked "Undo" and tried again!
If you have to use crappy OS or packages that are inclined to break things and put crap everywhere, VMWare is a delight!
(Yep, I'm just a happy customer.)
Your implication that the US government is entirely corrupt suggests you haven't lived any place outside the US, certainly not in any third-world country.
Here a president can't even get a blow job without a near miss at impeachment. And a year ago if you'd asked anybody to name one of the shadowy corporate moguls for whom Bush would be a sock puppet, anybody in California would have said "Kennie Lay of Enron". Now he's looking at a two-year-long colonoscopy by Congress and the press. And hopefully, jail time.
So "entirely corrupt" is way over the line. "Entirely corrupt" is when 30% of the government budget ends up in the pocket of the president and cabinet members. (Hello, Nigeria!) "Entirely corrupt" is when if you open your mouth you disappear in the middle of the night and they drop your body from a plane fifty miles out to sea. (Hello, Chile!)
Our ability to affect our government is far from theoretical. If you want to have more than 1/275,000,000 of the power, you can get it. Go get a master's in public policy from a top-notch school, go to Washington, and work your ass off. I know people who are doing it, and you can be one of them. Or if policy isn't to your tastes, go out and make a few million dollars and then fund people working on something that matters. There are always smart people looking for funding to change the world.
Maybe it isn't the case with you personally, but here in San Francisco 99% of the people who are bitching about how powerless they are don't do anything but bitch. If you wanna see this country move in your direction, you can't just ride along and yammer; you gotta hop off, roll up your sleeves, and push for all you're worth.
[...] you probably have $60 bucks somewhere. Just send them the money, [...]
Man, I tried that. I called them up a number of months back and said, "I already downloaded the latest version, and I don't need a box of manuals to throw out. Can I just give you the money?" It was impossible for normal sales reps to do that, but she kept promising to get in touch with her boss's boss, who could do it. I probably called the rep back five or six times before I gave up.
I know this is America, land of the fee, but you think it would be easier to give money away.
So I'm glad they're offering this; I'm gonna sign up so that they get my dough.
If it's a bug, it's not a big one. The worst case is that you get 4 * +1 to 5 and then you get 4 "overrated" scores, reducing your karma to 46. But if this happens to you again, you just end up back at 46. And the worst case is unlikely; more than likely 48 is the lowest this problem will ever take you.
Think of it as a karma cap of 45 with some room to take care of duelling moderator issues and you'll be fine with it.
I've used mod_gzip for the last year or so on a number of sites, one of which gets millions of hits a day. Trading idle CPU time in for drastically reduced bandwidth is a sweet bargain indeed. As a side benefit, those on slow links get a much faster experience.
Let's face it. Email etiquette is a niche.
One could make the same argument about any etiquette. And in some cases, like proper pinky placement while tea-sipping, the etiquette really is a niche, because the etiquette goes with something that is itself a niche. But that's not the case with email, which is rapidly becoming universal.
Any reasonable etiquette standard, from editing your email to not using your cellphone during a movie to not slurping your soup, is about consideration for others, about trading a little effort on your part for some benefit to those you deal with. To develop a taste for manners, all you need is the chance to regularly experience both sides of the behavior. A daily shower seems like an unnecessary nuisance until you sit next to somebody who bathes monthly.
Ever since the September that never ended, the Internet has been flooded with relative newbies. Newbies anywhere are notoriously short on manners. But the percentage of new people on the Internet has probably peaked already, so we should soon see some collective progress.
Certainly, I've seen signs of it. I've stopped receiving "send a card to tumorous Timmy" forward hoaxes; all my correspondents have passed that stage. And I've seen progress in the real world, too; during the last three movies I've attended, I haven't had to kill a single person for cellphone use.
And so it will go with quoting. A well-formatted message is more pleasant to read and easier to understand; those who want to communicate well will take the extra time. And those who don't catch on will look like dolts.
Like you, I sketch things out as I'm designing them, and then toss the diagrams when I'm done. But mainly, I use UML for communicating with people. When discussing design questions, it's great to be able to go to a whiteboard and sketch things as you talk about them.
People are much more likely to understand something when you communicate it via multiple modes, so description plus diagram is much better than either one on its own. And using UML rather than some home-grown notation makes it easier to communicate, as you don't have the questions of "What does that arrow mean again?"
.
Sure, this is "back-of-envelope" stuff, but just because you erase the diagrams doesn't mean they aren't valuable! The hard part about building software isn't the coding; it's the thinking about what to code.
Wasn't the goal to make it so that he didn't need another power supply?
I grant that for many Ask Slashdot questions, they would have been better off going to Google. But for things like this, you're missing the point.
He's not asking what exists, he's asking what people use and recommend. Most of the information that Google comes up with is marketing drivel. And even the personal opinions out there may not be helpful to us geeks: Slashdot readers are likely to be much more fussy about high-tech tools like this.
But the users don't want to write reports - they have other things to do.
Agreed! But if they can do it themselves in a few minutes or spend a few hours waiting for you to become available, most of them will do it themselves. Note the rise of Wal-Mart; people say they want service even if it costs a little more, but most of them really prefer cheap self-service.
I'm not saying you can automate everything away and just have them mail you your check. But in my experience, about 80% of what people want from reports is very similar. Giving them the power to do that easily (via, say, simple web-based report generators and data browsers) lets you devote your attention to the 20% of your report-writing that's actually interesting.
Report writing is my job.
Nope! Your job is to help people to get the information they need to do their jobs better.
Your boss may think your title is Senior Report Writer, but there's no need to confuse him by telling him the truth. By focusing on the need rather than a particular solution, you can have more fun and give the business more value for their money.
The path of "get a complete spec" can certainly work, but I find it awfully painful. For projects that are both novel and non-trivial, forcing the discovery of every detail up front can raise the total cost of the project significantly.
And then once you're working from a fixed spec, you have endless battles about whether request X is a feature (and therefore chargeable) or a bug fix (and therefore free). And all the energy spent on defending the spec from change and then negotiating the inevitable changes is energy I'd rather put into coding.
Personally, I prefer approaches like evolutionary delivery or Extreme Programming. The client gets to change their mind as much as they want as long as they're willing to pay the cost of changes. I find this makes them more thoughtful about the changes they want. Since they are getting working versions on a regular basis, they're much more mellow.
And generally the way we accomplish something in impossible times is to cut corners. Sure, it works in three weeks, but the code is snarled, there is no documentation, and you took advantage of a security hole to make it go.
Now of course you tell the manager, "If I spend three weeks on a temporary hack, I'm still going to have to spend another twelve weeks later doing it right."
And they say, "Sure! As soon as this crisis is past."
Of course, as soon as crisis A is done, crisis B is looming. And after B, then C, D, and E. So a lot of 'temporary' code gets written. Eventually, the project is just a big heap of steaming turds with some pretty contact paper covering most of the surface. And then the good programmers catch on and leave; the bad ones spend the rest of the lives sticking on more contact paper.
And the manager, of course, has long since moved on; he met his deadlines, after all, so he must be a good manager. And the person who's now in charge of that group? Well he must be a bad manager, because his team has lots of bugs and never makes deadlines anymore.
It's enough to make me cry.
He's saying more than that.
In my experience, most people turn up with both a rough list of features and a rough target date. It is very rare that they will want 100% of the features without regards to the date; instead, people are willing to cut features to bring things in on a schedule that suits them.
people producing the estimates aren't the people doing the actual work.
Absolutely true. Not only are the people doing the work more likely to give good estimates, but people also work much harder to meet their own estimates rather than somebody else's numbers.
estimate the amount of time it will take...then reduce that by 20%
Absolutely false. This is the worst thing you can do for morale. The programmers will know they are working to bullshit targets. And then when they miss the fake deadlines, they'll be stressed and grumpy for the last 20% of the work, meaning you'll get that last part slower and with poorer quality then you otherwise would have.