This means that referential integrity in the database serves more than to make up for bad middleware, it means that this is where business rules and other items that rarely change can be maintained. [...] Another thing that people often overlook is the fact that many times a database serves more than one application.
I don't overlook that; I actively repudiate that.
One of the fundamental notions of object-oriented programming is that is an object is data plus behavior. If you have several different chunks of code manipulating the same raw data, then that's not object-oriented programming. In which case, fine, throw out that Java and Python and go back to COBOL.
Theoretical reasons aside, there's a very practical reason for making sure that exactly one chunk of code reads and writes your raw persistent data: schema migration. As needs change, so will the schema of your persistent data. Keeping one code base in sync with that is, with much discipline, possible. But I've never seen any place that can keep multiple code bases in sync with new schemas.
If you can't migrate your schema, then you have massive design interia, meaning developers spend more and more time focusing on just making things work, rather than making new features. Which leads to dissatisfied executives, which leads all sorts of sadness.
Having your middleware control what items are stored in a table is just looking for trouble IMHO.
Without the right approach to development, this is true. With it, whether or not you're using a database at all becomes a peripheral question, rather than a central one.
I see software, regardless of architecture, as made up of three interconnected realms.
Interesting perspective.
And Prevaler looks to me to be just a memory RDBMS system, but I disagree with them that the db does *not* have to be stopped to dump the memory image to persistent storage. I feel that in some db apps, you would get bad results occasionally from some race conditions, which would be very difficult to track down.
I'm not sure what part of their literature you're referring to, but they can do what they say. One way is to leave the system open to reads but stop all writes when snapshotting. The other is to run two servers in parallel: the backup server pauses the command queue, does the snapshot, and then resumes processing the queued commands. Either way works; it just depends on your tolerance for delays.
Since Prevayler executes all writes serially, there are no race conditions in a Prevayler app.
My point here is that your accessor logic (so-called middleware) is what manifests the "foreign" relationship and if that's screwed then your app just doesn't work.
Well, there are two ways of looking at the typical system. Take a web application as an example: Either a) a database is where good objects go to rest when you don't need them, or b) your code is basically an engine for transforming HTTP requests into SQL statements, and then transforming SQL result sets into HTML.
I think you and I are in the first group. The database-centric approach is popular, but I think it is pretty limited, and it introduces too much design inertia. These days I just write my objects in code, and then use an O/R mapper like Hibernate to generate my SQL. If, that is, I use a database at all. Those who can't imagine life without databases should contemplate Google's architecture. Or take a look at Prevayler, a radically different way to build apps.
You've either got the middleware right or not.
Well, here I'd disagree. If referential integrity checks in the database are pretty cheap, I don't see anything wrong with a belt-and-suspenders approach. Even with extensive unit testing and pair programming, I can't so far get my bug rate much below one bug per month. If the database can catch some of those bugs sooner, I'm willing to trade a smidgen of performance.
Of course, as I'm writing this, it occurs to me that databases aren't so great for expressing all the constraints on the data anyhow; if I really want a mechanism for double-checking persistent data, I should just put it in the persistence layer. That would allow me to use the same mechanism on all data, persistent or not.
Ok! You've convinced me. Foreign key constraints are the wrong solution to the problem.
I also find a good set of 3x5 filecards (taped up to a whiteboard or large construction paper) an excellent starting point for my models, particularly when trying to model those main logical entities that end up driving the entire design.
Agreed! Index cards are a highly underrated technology. They're durable, easily manipulated, have a great UI, and can be used collaboratively. Plus, they don't cost $4k per user.
They have the advantage over whiteboards of being at least partially on paper should someone erase the board...
The more design I do, the less sure I get that durability is a benefit for design artifacts. After many years doing design the traditional way (with lots of documents and fancy diagrams), I switched a few years ago to doing things in the style of Extreme Programming.
It's now my feeling that any developer on a project should be able to sketch out the major objects and their relationships without much need for reference. If not, that's often a sign that the design is too confusing. And if they do need to check something, they should go right to the code: diagrams and documents get out of sync, but the source is always correct.
Of course, that means your source has to shine. It's hard work, but as Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
I will bet you my next five paychecks that this is not official Dell policy. Rather, this is an employee using a vague but believable pseudo-policy to end customer calls as quickly as he can, thereby improving the statistics that are used to evaluate him.
If Dell's official policy is to reward people for short call times and nothing else, then spewing bullshit like this might as well be Dell policy, too.
if you can buy locally from someone who can support you, do so.
Absolutely. A small business has tight enough feedback loops that they have the opportunity to learn that treating customers well is more than nice: it's good business. The feedback loop between some poor sap on Dell's support line and anything that means money to Dell is so long that it's very hard for them to get anything right.
It usually involves dinner (good food, what my dearly departed Great Depression-survivor grandma used to call "Reagan food,")
Heh. I once spent an entire morning helping a guy look at used 21" color monitors, back when they were a major investment. After much dithering, he finally picked one, and I helped him load the monster in his VW Bug, which was a major effort.
After all was said and done, he dropped me off at my place. Pointing to the two restaurants across the street, he said, "Hey, let me buy you lunch. Your choice! Burger King or McDonald's."
Now I only do free computer support for my mom. Everybody else pays cash.
I rent an office across town (just me in it) which allows me to create a routine of 'going to work' and 'leaving for home' which act as symbolic barriers to prevent me constantly being in work mode.
I used to work out of a home office; I've recently switched to renting an office. Happily, I have it in a shared office space, so I get many of the benefits of a job (e.g., people to chat with at the water cooler, lunch companions) without the hassles (e.g., office politics). It hasn't been very long, but so far I'm liking it. I especially like that when I'm home, I'm home.
Spammers already regularly do dictionary attacks against live mail servers. That also didn't sound practical, but that doesn't seem to be the case.
Not only is doing an MD5 hash on modern hardware pretty cheap, but unlike a dictionary attack against a mail server, it uses no bandwidth, has no latency issues, and cannot be detected or blocked by the site being attacked.
It is possible to reverse engineer some addresses, but you can stop that by sticking fake entries into the list.
That strikes me as legally dubious. Your fake entries have to be real enough that they'd be checked in a dictionary attack, meaning that you'll have to create, real-sounding addresses at major email domains. They'll have to be common enough that a big percentage will be fakes; spammers are used to dealing with low-quality spamming lists already. It will be hard to be sure that those don't exist and won't be taken by new users. If they do, then you'll be blocking spam from people who, legally, should be getting it.
The easiest solution to #2 is to have the database consist of MD5 hashes of email addresses. A potential advertiser could easily chech an address against the list but could not easily turn the list into addresses.
Wrong. If you allow the spammers to see the MD5 hashes, they can do dictionary attacks quickly against them. Domain names, after all, are public, and the local parts are mostly, nonrandom.
No, it's not. If it costs them $2 to get every $1 from you, they don't want your $1.
I'm not convinced they tried hard enough to change that ratio around.
For RH8, I downloaded it from somebody else, so I cost them zero bandwidth. Then I tried to give them money. There was no way on their site, their 800 number people couldn't fathom the notion, and I corresponded with all sorts of people trying to give them some dough before I finally threw up my hands.
For RH9, I downloaded it via BitTorrent, so even if they were seeding, that was approximately zero cost to them. And I made sure to leave the client seeding for quite a while, so my participation was net to their benefit. Not having the time to force them to take my money, next time I was at Frye's I bought their $40 box. I then promptly recycled everything but the CDs, which I might as well have thrown out too, as I've never needed them.
I looked at buying their update service, but paying $60 a year for each of my four personal boxes was crazy, and I tried paying them for just one, but it was too messy to manage the updates for the rest of the boxes separately.
So I've tried hard to give them money and bandwidth, and I've always given out plenty of free support on mailing lists. Plus, the reason I'm comfortable recommending Red Hat to clients is that I've used it for years for my own pet projects. By ending the distro I'm used to, they're forcing me to take a look at other distros. This move may be smart in the short term, but I think it's foolish in the long term.
Were I in their shoes, I'd have looked much harder for ways to take their biggest problem, their huge popularity on the low end of the marketplace, and make use of it. BitTorrent is a great example of a way to do that; it takes the problem of popularity and makes it into a solution. It's a shame they never found a way to take the money and support I wanted to give them!
Re:It is Christmas, give them what they REALLY wan
on
Christmas Bonuses?
·
· Score: 1
Just a thought : every employee secretly wishes he had some power to do something a little bit different, has something that drives him at work. Give them power, and money is power.
I'd still give them a little in cash, but this is an excellent notion. Not only will you learn about what workers really think they need, but you'll also get them feeling a lot more responsible for the company. One guy I know does this on his own; he just figures that 1% of his salary is given to him by his employer as discretionary work spending, because his employer knows how screwed up the purchasing processes are. He buys hardware, toys, or whatever else he thinks they need.
My other tip comes from when I used to work for financial traders. All the staff had a nominal salary, their market value. But anybody could take a lower salary and treat that as a bet on the company. If the company was even on the year, they just got the deferred salary as a bonus. If the company was up or down for the year, the deferred salary was multiplied accordingly.
It doesn't work for everybody, but if your employees are financially savvy and you're short on capital, this is a good way to go.
This can be pretty hard to justify on an expense report. My tip: find a fluffer and hire them as a LAN technician. Network techs spend a lot of time on their knees under desks anyhow, so likely nobody will notice the fluffer's activities. And if you get audited you can truthfully say that you made the hire based on their experience with cable management.
Here's a trick I stole from agile methods like Extreme Programming: build the test suite up at the same time you write the main code.
The main reason testing existing applications is so hard is that they aren't designed to be easily tested, so you have to jump through a lot of hoops to do proper testing. However, if the developers don't get to check anything off until their components are covered by unit tests and their features are covered by acceptance tests, that gives the developers the incentive to make the features easy to test.
On a recent Java web project, we used HttpUnit, a handy framework that simulates a web browser, including even a limited JavaScript processor. As we developed features, we built end-to-end tests that walked the web site and did all the things that users were supposed to do (or not supposed to do, like visiting admin-only pages). Sometimes it was the same person who built the feature, and sometimes it was somebody else on the team.
This doesn't mean that QA people are unneeded; a good QA person will think of many more edge cases than your average developer will, and they'll also think a lot more about keeping the site consistent as a whole. Instead, developers get a lot more respect for QA, as they discover that good testing is hard to do right.
Anyhow, if you've built feature tests as you built the main code, load tests are easy; you just run portions of the feature test suite from multiple boxes.
My big tip with this approach is to make sure to treat the test code with the same respect as the main code. Unless you refactor aggressively, it's easy to let it get messy. Once it's messy, people stop maintaining it. And once you stop maintaining it, developers can easily break features without anybody noticing.
Says who? Works pretty well for me. My team and I are generally *more* productive when we design *before* we code. Ever hear the saying, "Measure seven times, cut once"?
Having done things both ways, I'd say that incremental design improvement is the way to go.
Having done XP for a few years, I spend about 20% of my design time up front, about 30% while coding, and the rest while refactoring.
I like this a lot more than trying to do 100% of the design up front. Why? Because your design is only as good as the information you have at the time you do the design. For non-trival projects, it's impossible to have all the information you need up front; even if users never changed their minds once they saw the result (ha!), any good developer learns things as they go.
It also turns out to be much more productive. If I have to do all my design up front, I'm much more likely to overdesign; much better to have too much than too little. But if I do my design on a just-in-time basis, I can avoid a lot of needless work.
And as a bonus, my designs end up being better. The product may be version 1.0, but because I've been iterating over my architecture along the way, the architecture is version 5.0.
a team of programmers who [...] are given enough time to do the job right.
Heh. Safe of you to say that, as it never happens. Work always expands to more than fill the time available.
In my experience, one of the best things about XP is that it provides excellent mechanisms for scope control and quality control. With most projects I've seen, if the estimates are off teams make it up by writing crappy code and planning to "fix it later" (i.e., never). But with XP, quality is always kept at a high level, and scope is cut to match the time available.
If wewant to have enough time to do the job right, we have to adopt processes that make that happen. Expecting product managers to just give us enough time to do things right is like expecting a fox to guard the henhouse.
Give the less skilled one the keyboard. Force the skilled guy/girl to have to communicate all typing through the less skilled guy/girl.
This happens some in pair programming, but it's not the only way to do things. I'd say I spend maybe 5% of my pairing time dictating something. More common is when the person who knows whats going on seizes the keyboard and says, "Let me show you what I mean."
My general rule of thumb is that they keyboard should change hands every 10 minutes or so. Otherwise it's too easy for the driver to forget about the navigator, or for the navigator to zone out.
Pair programming is uncomfortable on our reduced space. And it's noisy.
Reduced space is bad. To do pair programming right, you need plenty of space, enough so that both people can sit side by side and see things well. I recommend a 6' x 4' table if you're using CRTs (with an LCD, you can use a shallower table).
Although it seems annoying it first, you'll get used to the conversation around you. Indeed, when I work in a silent area now, I really miss the background discussions, as they help keep me in touch with the rest of the team.
But if it still seems noisy after a while, ask yourself, "Is it really noise?" All of the conversation around you should be related to what you're working on. On-topic conversations shouldn't bother you, but off-topic stuff often will. XP is best done in a project room, a room (or area) specifically devoted to a single project.
Serious question: How does a CEO have the legal right to take company money for whatever he chooses instead of paying the employees? Doesn't he have a legal (and perhaps even overriding) responsibility to pay them?
For anybody employed in California, yes. Wages are not optional, and they must be paid first. How do I know? I had to get a lawyer to threaten my New York employer (now ex-employer, natch). But it's state law, so YMMV.
But generally, if a company is a sole proprietorship, the owner/boss has wide latitude do do as they please with the money. Bankruptcy courts have some power to investigate and reverse transactions, but from what I've seen are very reluctant to use it if it's vaguely plausible that the owner is merely an idiot.
If there are investors involved, it's messier; the CEO has more responsibility to not stuff his own pockets. And for a public company, it's much more strict.
Great answer! FYI, though, I wasn't asking you. I just wanted to make dubious9 think.
The answer I was fishing for was that just because an answer isn't acceptable doesn't mean it's not true. The confusion between what people want and what is really going on leads to a lot of scheduling mistakes: if you pressure programmers to give lower estimates, they will. They'll be worse estimates, of course.
Break the tasks up into incredible small chunks and use those to estimate times.[...] Or you can back rev it into the timeline : ask the team 'what can you get done in 9 months [...] start slashing functionality to get the estimate down to 4 months if you really need to go live in 9 months.
Breaking it down into tiny tasks is a great technique. It's often been my experience that if I make programmers break a two-week task into 1-2 day tasks, the total ends up being closer to 15 than 10.
But instead of the generic 2x rule, there's a way to find out the value for local conditions: short iterations with a feedback loop. If you start with the team's 9-month plan, tell them that the original estimates should be thought of arbitrary points, which correspond to 1 ideal day of work. Tell them that the goal of the game is to figure out the relationship between ideal days and real days. Then have them pick out a week's worth of work and work for a week.
At end of the week, count up the number of points that are 100% done. (And this is really 100% done, as in tested, complete, and of shippable quality. If you have a QA department, give it to QA right then.) That number of points will be something less than 5 per engineer. That number is now your "velocity"; for the next week, pick out that many points worth (or maybe a couple more if you think things will improve) and do 'em.
In my experience, the velocity number stabilizes after a month or so. That will let you figure out what you're likely to get 8 months later. But it's still worth doing the weekly iterations and tracking velocity; it gives you hard data that is immensely useful, especially in convincing management of things. E.g., that when you say "August" you have good reason for it, and leaning on you is not the way to get it to be "June".
Tired people are slow, mistake-prone and unproductive.
Yes. People who have the macho more-hours-is-better attitude do not measure their productivity. If they did, they would discover that they are just wasting everybody's time in an effort to look tough.
This is especially true with programming; one careless bit of coding can turn into hours of debugging. And tired people write messy, over-complicated code, turning those hours into days. When I get a cowboy on a team, I try to rehabilitate them, but if I couldn't get them to work sane hours, I would unhesitatingly fire them.
PS If anyone knows an OSS MS Project replacement that can do all this stuff, please speak up.
I used index cards on a big cork board. The board has one row for each week. Each card has an estimate on the upper right corner. No row is allowed to have more than a week's worth of work in it.
For me, I find that five or six rows is plenty: that gives me a week of history and a month of upcoming stuff. For things beyond that, there is an envelope marked "later" at the bottom right corner of the board.
Every week, we get together with the powers that be, get them to check off the cards that are done, re-estimate any of the cards whose estimates now seem off. Then we lay out the upcoming month, filling in stuff from the "later" envelope. Once in a while, people want estimates that go beyond the month. We clear off a big table and lay out more cards until they have the answers they need.
This works really well. It is not as pretty as MS Project, and sometimes PMs will take the data from the cards and put it in Project so that they can print pretty reports. But the ugliness is more than made up for by the fact that everybody can understand and manipulate index cards. Even better, they are forced to see it: it's in a prominent place in the project room.
I believe I will somewhat concur with the 1.2 per person calculation, I find the rest of your estimations completely bullshit. Newbies may not have the skill to estimate acurately, but 8x? So your saying if a newbie programmer think it'll take a month to do something, it really takes eight? That is not an acceptable time schedule.
I agree that it is not acceptable time schedule. I also agree with the OP about his scaling factors; in my experience, they are about right. How can you reconcile the two?
You need to explain to people what it will take to get the task done. The bigger trick may be explaining this to them without their eyes glazing over.
Not necessarily. Instead of breaking the work down by your tasks and explaning it to them, you can also break the work down into things that are visible and comprehensible to them.
So if you're making the classic shopping cart app, you might deliver the home page one week. Then next week, a simple product catalog with only two fields (item number and title) and some sample records. Then you could add prices. And so on.
Doing it this way can result in a little more programmer work. But it turns out that when you show people the work one piece at a time, they often figure out what they want sooner, reducing rework. In my experience so far, it's more than paid off.
Even better, you get to take advantage of their impatience. When you show them the timeline as the sum of the features they want, then they get to argue with themselves about what's most important. On a project I just finished, the PM happily cut scope to get the stuff out the door by their previously impossible deadline. That's much more productive behavior than leaning on the developers to work weekends.
Slashdot Mirror
After much grovelling through the vendor catalog
That's a great image, but perhaps you should check a dictionary. Either that, or you need to start dealing with more friendly vendors.
This means that referential integrity in the database serves more than to make up for bad middleware, it means that this is where business rules and other items that rarely change can be maintained. [...] Another thing that people often overlook is the fact that many times a database serves more than one application.
I don't overlook that; I actively repudiate that.
One of the fundamental notions of object-oriented programming is that is an object is data plus behavior. If you have several different chunks of code manipulating the same raw data, then that's not object-oriented programming. In which case, fine, throw out that Java and Python and go back to COBOL.
Theoretical reasons aside, there's a very practical reason for making sure that exactly one chunk of code reads and writes your raw persistent data: schema migration. As needs change, so will the schema of your persistent data. Keeping one code base in sync with that is, with much discipline, possible. But I've never seen any place that can keep multiple code bases in sync with new schemas.
If you can't migrate your schema, then you have massive design interia, meaning developers spend more and more time focusing on just making things work, rather than making new features. Which leads to dissatisfied executives, which leads all sorts of sadness.
Having your middleware control what items are stored in a table is just looking for trouble IMHO.
Without the right approach to development, this is true. With it, whether or not you're using a database at all becomes a peripheral question, rather than a central one.
I see software, regardless of architecture, as made up of three interconnected realms.
Interesting perspective.
And Prevaler looks to me to be just a memory RDBMS system, but I disagree with them that the db does *not* have to be stopped to dump the memory image to persistent storage. I feel that in some db apps, you would get bad results occasionally from some race conditions, which would be very difficult to track down.
I'm not sure what part of their literature you're referring to, but they can do what they say. One way is to leave the system open to reads but stop all writes when snapshotting. The other is to run two servers in parallel: the backup server pauses the command queue, does the snapshot, and then resumes processing the queued commands. Either way works; it just depends on your tolerance for delays.
Since Prevayler executes all writes serially, there are no race conditions in a Prevayler app.
My point here is that your accessor logic (so-called middleware) is what manifests the "foreign" relationship and if that's screwed then your app just doesn't work.
Well, there are two ways of looking at the typical system. Take a web application as an example: Either a) a database is where good objects go to rest when you don't need them, or b) your code is basically an engine for transforming HTTP requests into SQL statements, and then transforming SQL result sets into HTML.
I think you and I are in the first group. The database-centric approach is popular, but I think it is pretty limited, and it introduces too much design inertia. These days I just write my objects in code, and then use an O/R mapper like Hibernate to generate my SQL. If, that is, I use a database at all. Those who can't imagine life without databases should contemplate Google's architecture. Or take a look at Prevayler, a radically different way to build apps.
You've either got the middleware right or not.
Well, here I'd disagree. If referential integrity checks in the database are pretty cheap, I don't see anything wrong with a belt-and-suspenders approach. Even with extensive unit testing and pair programming, I can't so far get my bug rate much below one bug per month. If the database can catch some of those bugs sooner, I'm willing to trade a smidgen of performance.
Of course, as I'm writing this, it occurs to me that databases aren't so great for expressing all the constraints on the data anyhow; if I really want a mechanism for double-checking persistent data, I should just put it in the persistence layer. That would allow me to use the same mechanism on all data, persistent or not.
Ok! You've convinced me. Foreign key constraints are the wrong solution to the problem.
I also find a good set of 3x5 filecards (taped up to a whiteboard or large construction paper) an excellent starting point for my models, particularly when trying to model those main logical entities that end up driving the entire design.
Agreed! Index cards are a highly underrated technology. They're durable, easily manipulated, have a great UI, and can be used collaboratively. Plus, they don't cost $4k per user.
They have the advantage over whiteboards of being at least partially on paper should someone erase the board...
The more design I do, the less sure I get that durability is a benefit for design artifacts. After many years doing design the traditional way (with lots of documents and fancy diagrams), I switched a few years ago to doing things in the style of Extreme Programming.
It's now my feeling that any developer on a project should be able to sketch out the major objects and their relationships without much need for reference. If not, that's often a sign that the design is too confusing. And if they do need to check something, they should go right to the code: diagrams and documents get out of sync, but the source is always correct.
Of course, that means your source has to shine. It's hard work, but as Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
I will bet you my next five paychecks that this is not official Dell policy. Rather, this is an employee using a vague but believable pseudo-policy to end customer calls as quickly as he can, thereby improving the statistics that are used to evaluate him.
If Dell's official policy is to reward people for short call times and nothing else, then spewing bullshit like this might as well be Dell policy, too.
if you can buy locally from someone who can support you, do so.
Absolutely. A small business has tight enough feedback loops that they have the opportunity to learn that treating customers well is more than nice: it's good business. The feedback loop between some poor sap on Dell's support line and anything that means money to Dell is so long that it's very hard for them to get anything right.
It usually involves dinner (good food, what my dearly departed Great Depression-survivor grandma used to call "Reagan food,")
Heh. I once spent an entire morning helping a guy look at used 21" color monitors, back when they were a major investment. After much dithering, he finally picked one, and I helped him load the monster in his VW Bug, which was a major effort.
After all was said and done, he dropped me off at my place. Pointing to the two restaurants across the street, he said, "Hey, let me buy you lunch. Your choice! Burger King or McDonald's."
Now I only do free computer support for my mom. Everybody else pays cash.
I rent an office across town (just me in it) which allows me to create a routine of 'going to work' and 'leaving for home' which act as symbolic barriers to prevent me constantly being in work mode.
I used to work out of a home office; I've recently switched to renting an office. Happily, I have it in a shared office space, so I get many of the benefits of a job (e.g., people to chat with at the water cooler, lunch companions) without the hassles (e.g., office politics). It hasn't been very long, but so far I'm liking it. I especially like that when I'm home, I'm home.
It is still not very practical.
Spammers already regularly do dictionary attacks against live mail servers. That also didn't sound practical, but that doesn't seem to be the case.
Not only is doing an MD5 hash on modern hardware pretty cheap, but unlike a dictionary attack against a mail server, it uses no bandwidth, has no latency issues, and cannot be detected or blocked by the site being attacked.
It is possible to reverse engineer some addresses, but you can stop that by sticking fake entries into the list.
That strikes me as legally dubious. Your fake entries have to be real enough that they'd be checked in a dictionary attack, meaning that you'll have to create, real-sounding addresses at major email domains. They'll have to be common enough that a big percentage will be fakes; spammers are used to dealing with low-quality spamming lists already. It will be hard to be sure that those don't exist and won't be taken by new users. If they do, then you'll be blocking spam from people who, legally, should be getting it.
The easiest solution to #2 is to have the database consist of MD5 hashes of email addresses. A potential advertiser could easily chech an address against the list but could not easily turn the list into addresses.
Wrong. If you allow the spammers to see the MD5 hashes, they can do dictionary attacks quickly against them. Domain names, after all, are public, and the local parts are mostly, nonrandom.
No, it's not. If it costs them $2 to get every $1 from you, they don't want your $1.
I'm not convinced they tried hard enough to change that ratio around.
For RH8, I downloaded it from somebody else, so I cost them zero bandwidth. Then I tried to give them money. There was no way on their site, their 800 number people couldn't fathom the notion, and I corresponded with all sorts of people trying to give them some dough before I finally threw up my hands.
For RH9, I downloaded it via BitTorrent, so even if they were seeding, that was approximately zero cost to them. And I made sure to leave the client seeding for quite a while, so my participation was net to their benefit. Not having the time to force them to take my money, next time I was at Frye's I bought their $40 box. I then promptly recycled everything but the CDs, which I might as well have thrown out too, as I've never needed them.
I looked at buying their update service, but paying $60 a year for each of my four personal boxes was crazy, and I tried paying them for just one, but it was too messy to manage the updates for the rest of the boxes separately.
So I've tried hard to give them money and bandwidth, and I've always given out plenty of free support on mailing lists. Plus, the reason I'm comfortable recommending Red Hat to clients is that I've used it for years for my own pet projects. By ending the distro I'm used to, they're forcing me to take a look at other distros. This move may be smart in the short term, but I think it's foolish in the long term.
Were I in their shoes, I'd have looked much harder for ways to take their biggest problem, their huge popularity on the low end of the marketplace, and make use of it. BitTorrent is a great example of a way to do that; it takes the problem of popularity and makes it into a solution. It's a shame they never found a way to take the money and support I wanted to give them!
Just a thought : every employee secretly wishes he had some power to do something a little bit different, has something that drives him at work. Give them power, and money is power.
I'd still give them a little in cash, but this is an excellent notion. Not only will you learn about what workers really think they need, but you'll also get them feeling a lot more responsible for the company. One guy I know does this on his own; he just figures that 1% of his salary is given to him by his employer as discretionary work spending, because his employer knows how screwed up the purchasing processes are. He buys hardware, toys, or whatever else he thinks they need.
My other tip comes from when I used to work for financial traders. All the staff had a nominal salary, their market value. But anybody could take a lower salary and treat that as a bet on the company. If the company was even on the year, they just got the deferred salary as a bonus. If the company was up or down for the year, the deferred salary was multiplied accordingly.
It doesn't work for everybody, but if your employees are financially savvy and you're short on capital, this is a good way to go.
Lots and lots of whores!
This can be pretty hard to justify on an expense report. My tip: find a fluffer and hire them as a LAN technician. Network techs spend a lot of time on their knees under desks anyhow, so likely nobody will notice the fluffer's activities. And if you get audited you can truthfully say that you made the hire based on their experience with cable management.
Here's a trick I stole from agile methods like Extreme Programming: build the test suite up at the same time you write the main code.
The main reason testing existing applications is so hard is that they aren't designed to be easily tested, so you have to jump through a lot of hoops to do proper testing. However, if the developers don't get to check anything off until their components are covered by unit tests and their features are covered by acceptance tests, that gives the developers the incentive to make the features easy to test.
On a recent Java web project, we used HttpUnit, a handy framework that simulates a web browser, including even a limited JavaScript processor. As we developed features, we built end-to-end tests that walked the web site and did all the things that users were supposed to do (or not supposed to do, like visiting admin-only pages). Sometimes it was the same person who built the feature, and sometimes it was somebody else on the team.
This doesn't mean that QA people are unneeded; a good QA person will think of many more edge cases than your average developer will, and they'll also think a lot more about keeping the site consistent as a whole. Instead, developers get a lot more respect for QA, as they discover that good testing is hard to do right.
Anyhow, if you've built feature tests as you built the main code, load tests are easy; you just run portions of the feature test suite from multiple boxes.
My big tip with this approach is to make sure to treat the test code with the same respect as the main code. Unless you refactor aggressively, it's easy to let it get messy. Once it's messy, people stop maintaining it. And once you stop maintaining it, developers can easily break features without anybody noticing.
Says who? Works pretty well for me. My team and I are generally *more* productive when we design *before* we code. Ever hear the saying, "Measure seven times, cut once"?
Having done things both ways, I'd say that incremental design improvement is the way to go.
Having done XP for a few years, I spend about 20% of my design time up front, about 30% while coding, and the rest while refactoring.
I like this a lot more than trying to do 100% of the design up front. Why? Because your design is only as good as the information you have at the time you do the design. For non-trival projects, it's impossible to have all the information you need up front; even if users never changed their minds once they saw the result (ha!), any good developer learns things as they go.
It also turns out to be much more productive. If I have to do all my design up front, I'm much more likely to overdesign; much better to have too much than too little. But if I do my design on a just-in-time basis, I can avoid a lot of needless work.
And as a bonus, my designs end up being better. The product may be version 1.0, but because I've been iterating over my architecture along the way, the architecture is version 5.0.
a team of programmers who [...] are given enough time to do the job right.
Heh. Safe of you to say that, as it never happens. Work always expands to more than fill the time available.
In my experience, one of the best things about XP is that it provides excellent mechanisms for scope control and quality control. With most projects I've seen, if the estimates are off teams make it up by writing crappy code and planning to "fix it later" (i.e., never). But with XP, quality is always kept at a high level, and scope is cut to match the time available.
If wewant to have enough time to do the job right, we have to adopt processes that make that happen. Expecting product managers to just give us enough time to do things right is like expecting a fox to guard the henhouse.
Give the less skilled one the keyboard. Force the skilled guy/girl to have to communicate all typing through the less skilled guy/girl.
This happens some in pair programming, but it's not the only way to do things. I'd say I spend maybe 5% of my pairing time dictating something. More common is when the person who knows whats going on seizes the keyboard and says, "Let me show you what I mean."
My general rule of thumb is that they keyboard should change hands every 10 minutes or so. Otherwise it's too easy for the driver to forget about the navigator, or for the navigator to zone out.
Pair programming is uncomfortable on our reduced space. And it's noisy.
Reduced space is bad. To do pair programming right, you need plenty of space, enough so that both people can sit side by side and see things well. I recommend a 6' x 4' table if you're using CRTs (with an LCD, you can use a shallower table).
Although it seems annoying it first, you'll get used to the conversation around you. Indeed, when I work in a silent area now, I really miss the background discussions, as they help keep me in touch with the rest of the team.
But if it still seems noisy after a while, ask yourself, "Is it really noise?" All of the conversation around you should be related to what you're working on. On-topic conversations shouldn't bother you, but off-topic stuff often will. XP is best done in a project room, a room (or area) specifically devoted to a single project.
Serious question: How does a CEO have the legal right to take company money for whatever he chooses instead of paying the employees? Doesn't he have a legal (and perhaps even overriding) responsibility to pay them?
For anybody employed in California, yes. Wages are not optional, and they must be paid first. How do I know? I had to get a lawyer to threaten my New York employer (now ex-employer, natch). But it's state law, so YMMV.
But generally, if a company is a sole proprietorship, the owner/boss has wide latitude do do as they please with the money. Bankruptcy courts have some power to investigate and reverse transactions, but from what I've seen are very reluctant to use it if it's vaguely plausible that the owner is merely an idiot.
If there are investors involved, it's messier; the CEO has more responsibility to not stuff his own pockets. And for a public company, it's much more strict.
Delcom Engineering makes some cool USB-controlled lights, buttons, and numeric LED displays.
Thinkgeek also has a USB volume knob.
-How can you reconcile the two?
Great answer! FYI, though, I wasn't asking you. I just wanted to make dubious9 think.
The answer I was fishing for was that just because an answer isn't acceptable doesn't mean it's not true. The confusion between what people want and what is really going on leads to a lot of scheduling mistakes: if you pressure programmers to give lower estimates, they will. They'll be worse estimates, of course.
Break the tasks up into incredible small chunks and use those to estimate times.[...] Or you can back rev it into the timeline : ask the team 'what can you get done in 9 months [...] start slashing functionality to get the estimate down to 4 months if you really need to go live in 9 months.
Breaking it down into tiny tasks is a great technique. It's often been my experience that if I make programmers break a two-week task into 1-2 day tasks, the total ends up being closer to 15 than 10.
But instead of the generic 2x rule, there's a way to find out the value for local conditions: short iterations with a feedback loop. If you start with the team's 9-month plan, tell them that the original estimates should be thought of arbitrary points, which correspond to 1 ideal day of work. Tell them that the goal of the game is to figure out the relationship between ideal days and real days. Then have them pick out a week's worth of work and work for a week.
At end of the week, count up the number of points that are 100% done. (And this is really 100% done, as in tested, complete, and of shippable quality. If you have a QA department, give it to QA right then.) That number of points will be something less than 5 per engineer. That number is now your "velocity"; for the next week, pick out that many points worth (or maybe a couple more if you think things will improve) and do 'em.
In my experience, the velocity number stabilizes after a month or so. That will let you figure out what you're likely to get 8 months later. But it's still worth doing the weekly iterations and tracking velocity; it gives you hard data that is immensely useful, especially in convincing management of things. E.g., that when you say "August" you have good reason for it, and leaning on you is not the way to get it to be "June".
Tired people are slow, mistake-prone and unproductive.
Yes. People who have the macho more-hours-is-better attitude do not measure their productivity. If they did, they would discover that they are just wasting everybody's time in an effort to look tough.
This is especially true with programming; one careless bit of coding can turn into hours of debugging. And tired people write messy, over-complicated code, turning those hours into days. When I get a cowboy on a team, I try to rehabilitate them, but if I couldn't get them to work sane hours, I would unhesitatingly fire them.
PS If anyone knows an OSS MS Project replacement that can do all this stuff, please speak up.
I used index cards on a big cork board. The board has one row for each week. Each card has an estimate on the upper right corner. No row is allowed to have more than a week's worth of work in it.
For me, I find that five or six rows is plenty: that gives me a week of history and a month of upcoming stuff. For things beyond that, there is an envelope marked "later" at the bottom right corner of the board.
Every week, we get together with the powers that be, get them to check off the cards that are done, re-estimate any of the cards whose estimates now seem off. Then we lay out the upcoming month, filling in stuff from the "later" envelope. Once in a while, people want estimates that go beyond the month. We clear off a big table and lay out more cards until they have the answers they need.
This works really well. It is not as pretty as MS Project, and sometimes PMs will take the data from the cards and put it in Project so that they can print pretty reports. But the ugliness is more than made up for by the fact that everybody can understand and manipulate index cards. Even better, they are forced to see it: it's in a prominent place in the project room.
I believe I will somewhat concur with the 1.2 per person calculation, I find the rest of your estimations completely bullshit. Newbies may not have the skill to estimate acurately, but 8x? So your saying if a newbie programmer think it'll take a month to do something, it really takes eight? That is not an acceptable time schedule.
I agree that it is not acceptable time schedule. I also agree with the OP about his scaling factors; in my experience, they are about right. How can you reconcile the two?
You need to explain to people what it will take to get the task done. The bigger trick may be explaining this to them without their eyes glazing over.
Not necessarily. Instead of breaking the work down by your tasks and explaning it to them, you can also break the work down into things that are visible and comprehensible to them.
So if you're making the classic shopping cart app, you might deliver the home page one week. Then next week, a simple product catalog with only two fields (item number and title) and some sample records. Then you could add prices. And so on.
Doing it this way can result in a little more programmer work. But it turns out that when you show people the work one piece at a time, they often figure out what they want sooner, reducing rework. In my experience so far, it's more than paid off.
Even better, you get to take advantage of their impatience. When you show them the timeline as the sum of the features they want, then they get to argue with themselves about what's most important. On a project I just finished, the PM happily cut scope to get the stuff out the door by their previously impossible deadline. That's much more productive behavior than leaning on the developers to work weekends.