IMHO if QA cannot keep track of the big picture they fail as QA, because that is just an important part of their job. On the other hand perhaps extreme programming should involve relatively more QA people than 'regular' development methods.
On an XP project, much more QA work certainly gets done than on your average project. One important component of XP are the customer tests, which are automated tests that are used to decide whether or not programmers are done with a particular feature.
Whether there are special QA people who write those tests is a local decision, but good QA people have the right orientation to write really good customer tests.
In fact, a sign of a well-run WebObjects project is that for the first week or two, most of the developers are sitting on their hands or taking long lunches or reading Slashdot. During this time, however, the senior person or two is taking the time to get the underlying data object model right. Only when that is solid does the manager unleash the rest of the troops.
Or not.
Many people use EOF with Agile methods, which generally treat design as something that should be done on a just-in-time basis, rather than in a big up-front spurt. Indeed, EOF works even better with Agile projects than with traditional once, as it makes continuous schema evolution much easier.
Whether it's a schema change or a data change, a change like that mid-way through development is a serious decision, and shouldn't be undertaken lightly.
That's one way to develop.
Or, instead, you could assume that change is a given and tune your development process for that.
The DBA and developers need to work together to work out an ideal schema. Ideally, it's msotly worked out *before* any coding is done. DB objects should not be done on the fly in msot cases.
Yes, ideally all requirements are identified, and then all the design is done, and then all of the code is written. Ideally. And ideally, you could remove the backspace key from they keyboard.
Alas, most of us don't get to code in an ideal world. The premise behind the various Agile methods (Extreme Programming, Crystal, Scrum, FDD, etc.) is that since the world isn't ideal, we might as well pick development methods that are tuned for the world we live in.
However, beyond cleaning duplication, keep the SQL near where it is used. [...] However, a more balanced approach is the use the full power the DBMS rather than re-invent it in your application. [...] Thus, either get an OODBMS, or relax the OO design to not duplicate and fight with the RDB and query languages.
I agree that OO and relational thinking are at odds, and that mixing them produces poor results. But if you do good OO design, then the kind of database you use shouldn't be a big issue.
The trick is to put all your persistence logic in one tier of the code. I have one app that will happily use several different backing stores (java serialization, XML files, and SQL storage) at the change of a config line. I could easily add code to use an OO database or an LDAP database.
As long as you design that way, there's very little "fighting with the RDB" to do.
Sometimes I think many OO'ers are motivated by a desire for control, and that is why they would rather reinvent the DB rather than use an existing one. But that is anti-reuse IMO.
Just because you have a database that can do something doesn't mean that you should do it there.
Java, for example, has handy built-in stuff for indexing, joins, filtering, and multi-user contention management. I can happily reuse that, remaining database neutral. Better, most outfits have many more programmers than DBAs; if the logic is in the code rather than the database, I have higher development concurrency and a better truck factor.
Reuse is swell, but as a developer my responsibility is to efficiently deliver good software and keep it up over the long term. RDBs are one tool I'll use to achieve this, but only when they deliver the best business value.
What I really am not crazy about in the article is that it fails to realize that databases live on.
You're close, but you're not quite there yet.
What really should live on is the data, not a particular database or a particular schema. The reasons that applications have to come and go is that they aren't being maintained properly. And one of the big brakes on proper refactoring is database schemas that aren't allowed to change.
If you force your database schemas to evolve along with the application (which in turn is forced to evolve along with your business) then everybody wins. Well, everybody except the Oracle marketroid trying to sell you yet more magic bullets.
relational databases [...] really are the backbone of information systems in business [...] object-oriented [...] "databases", although aesthetically prettier, have adverse effects on performance and design. Programmers get lazy, applications become sloppy and performance goes into the toilet.
For procedural code, you are very right. For object-oriented code, though, relational databases are dangerous. Why?
One problem is that rectangular tables don't map particularly well to hierachies of objects. This results in either distorted OO models or database layouts that look weird to DBAs (and are therefore hard to optimize).
Another big problem is that they encourage procedural thinking. There is an awful lot of Java code out there that isn't in any sense object oriented; it is so procedural that it might as well be written in COBOL.
A third is that they encourage leakage between layers. I don't know how much code I've seen where SQL is scattered fucking everywhere, rather than isolated to a persistence tier. Sure, you can say that programmers shouldn't do that, but when faced with a deadline, an awful lot of developers will cough up some SQL hairball rather than fixing the underlying design issue.
A fourth is that since the schema duplicates information in your code, this acts as a brake on refactoring. If you use a Martin Fowler's tricks for keeping the database in sync (or if you use a good O/R mapper) you can survive this, but it's still a pain.
And a fifth is that once the database exists, no matter how much the original designers warn against it, people start using the database as an integration layer. Suddenly 14 different apps are munging the same data, making it impossible to change the schema, and nearly as hard to track down a bug. The whole point of OO programming is that data should always be wrapped by the code that goes with it.
But my biggest gripe about them is that for 90% of the OO apps out there, an SQL engine just isn't necessary, and only serves to slow things at development and again at runtime.
That's not to say that SQL databases aren't sometimes useful, just that they aren't a magic bullet, and they lead an awful lot of people astray. For those OO developers out there, check out Prevayler. As long as your dataset fits in RAM (and really, how much does RAM cost these days?) you can simplify your code and improve performance by thousands of times.
Even for those who can't use something like Prevayler because the dataset is too large, it's a valuable thought exercise to demonstrate that databases need not be objects of worship.
The stats on those watches look pretty sad. The ones mentioned at the top of this article can supposedly 0.00001mSv/h. The ones at pro-resources.net bottom out at 0.1 mSv/h.
Since background radiation appears to be circa 0.0002 mSv/h, the watch at pro-resources.net apparently will only detect levels 500x normal. They should just get rid of the digital display and just show RARE, MEDIUM, or WELL DONE.
It's very close to, "Do all the analysis, do all the design (down to the level of specifying subroutines), do a little estimating on top of that, and you're done."
Agreed. What I meant is that it's a step away from running a project on bullshit. Eventually, he'll probably realize that there's no good reason to do the detailed design for next year's features before you start next week's features. Then he can take a hint from the just-in-time manufacturing industry and move towards just-in-time design.
XP would say Big Design Up Front doesn't work, but the Planning Game (with "user story" cards as you describe) does. I understand how that works for a single iteration, but not how well it works for a substantial (more than ten staff years) project.
You can think of XP as self-similar across time scales. The basic behaviors (planning, designing, coding, testing, refactoring, integrating, getting feedback) should happen more or less continuously, even on the scale of an individual hour.
So a a release planning meeting (which might happen every 1-3 months) look a lot like an iteration planning meeting (which happens every 1-3 weeks). Which in turn looks a lot like what happens with an individual task. The granularity gets smaller, but it feels very similar.
Or another way to look at it is that after the first iteration is done, an XP project is in maintenance mode. Ergo, you could say that the main difference between a 10-person, 3-month XP project and a 10-person, 3-year one is that the latter is just longer. This means you have more (more releases, more tests, more code, more confidence in estimating, more changes in requirements), but it's essentially the same thing.
As consumers, it isn't our responsibility and it isn't possible for us to make sure the businesses we consume from are "viable". As users of open source software, it isn't our responsibility and it isn't possible for us to make sure that an opensource business remains "viable".
Now substitute "employers" for "consumers" and "employees" for "businesses". Still like the way it sounds?
This has a bunch of good advice. Joel is about 50% of the way to inventing Extreme Programming (or yet another Agile methodology) on his own.
The things I'd change:
Chances are, debugging took from 100% - 200% of the time it took to write the code in the first place. This has to be a line item in the schedule, and it will probably be the largest line item.
Sweet jesus! Spending this much time debugging is a bad sign. If you're going to be spending 50-66% of programming time on something, then spend it on automated tests. The best way is to write them before the code, and not in a big lump, either. Write one little test, then write the code to make it pass.
If you spend the time on automated tests instead of debugging, then you won't just finish with a solid program; you'll also end up with a giant suite of tests that makes sure you never break anything.
Put integration time into the schedule.
Sure, putting integration time is better than the typical practice where everybody covers their ears and shouts, "la-la-la-la" when somebody brings this up.
But better still is to make sure that integration happens all the time. It's perfectly possible to check in code at least daily (I check in on average every 20 minutes or so) and to have shippable versions at least once a week.
Really good cooks clean up as they work, so they kitchen is always in pretty good shape. Programmers can learn from this.
The standard format I use for schedules is so simple you can memorize it. You start with just seven columns...
It can be simpler. The Extreme Programming style is to write the name of each feature on a card. Each card is given an estimate of 1, 2, or 3 points; that number is written on one corner of the card. Points are arbitrary, but the units should work out so that a team can do 5-20 points every (generally one-week) iteration. Cards that are bigger than 3 points are torn up; new cards are written that break the big feature down into lots of little ones.
Then the team does an iteration. However many points they get done, that's this week's "velocity".
Which cards to do first? Well, that's a business question, not a technical one. Ergo, the business people should put the cards in order by business value, and programmers should just take 'em off the top.
When do you release? Well, that's a business decision, too. I like putting special colored marker cards in the pile called "release 1", "release 2", etc. The business people can put those where they want.
What's the schedule? When somebody asks, hand them the cards, tell them your current velocity, and let them count their way down the stack to whatever point they are interested in. If they don't like the answer, tell them they are welcome to a) hire more staff, or b) rearrange the cards until they get an answer they like better.
This sounds glib, but it works. I recently got called into a project, already late, where a client handed me a vague 1-page spec for a subsystem and said, "You can have all this done in 5 weeks, right?"
Rather than laughing, I led him through the put-it-on-cards exercise and started working. In the end, we shipped on time, but with only half the original features that he asked for. But since he made all the choices about what to work on when, he wasn't pissed, he was delighted!
if you found the job yourself and was told to go to a 'body shop' to front-end you, you are really bringing the business to the body shop and you should know that the body shop should take about 23% of your income.
I used the shell-company-for-hire ZeroChaos for six months or so last year and was quite happy with them. The employer paid the fee on that one, but my recollection was that ZeroChaos charges a flat $300 per month.
You still have to pay all the various taxes that you would as an independent, but that's still better than 23%. And ZeroChaos also would let you buy benefits (including health insurance and a 401k) through them, which saves some hassle.
Recently, our director mentioned that she expected at least 50-60 hours per week, every week from all professional, salaried staff (we have about 20-25 people in that category. Our "official" workday is 7.5 hours. In essence, we're being told that we have to work a minimum of 10-12 hour days every week of the year and more when we have critical needs.
To a naive manager, this sounds appealing. For her salary budget, she has increased productivity by 25-50%!
But this is mainly proof that she isn't measuring productivity. If she were, she'd discover that compulsory overtime doesn't buy her anything in the long term, and probably hurts her. The studies I've looked at (see McConnell's "Rapid Development" for references to good research on the topic) suggest that if you make people spend that much time in the office, they spend a lot of it on doing things other than work.
And if they are programmers, it's even worse. When pressured to go faster, they skip testing, don't polish their code, and ignore big issues until "later". When programmers are tired, they make more mistakes. But since they are testing and polishing less, they find those mistakes later or not at all.
This pushes software projects into a downward spiral: increased bug counts and increased time-per-bug yield slipped schedules. Slipped schedules create more time pressure. More time pressure creates buggier, messier code. Eventually, everything blows up, but generally after the manager who created the problem has moved on.
The solution: taking the time to do it right is the fastest way to get it done:
Write automated unit tests
Integrate frequently (I integrate every hour or two; daily integration is a minimum)
Work in short iterations (1-2 weeks)
program in pairs (if you can't, then frequent code reviews are the next best thing)
measure your productivity
That last one is especially important. Now that I measure my own productivity, I've discovered that it's better to stop coding when I get tired; otherwise I start making mistakes that cost me later. Then when your boss says, "Everybody must work 60 hours a week until the product ships!" you can say, "What effect do you think that will have on productivity? And if it turns out that 40-hour weeks are the fastest way to get things done, will you go back to them?"
There are surprisingly recent OSes that stil can't limit relaying to specific hosts; it's all (open) or nothing (closed).
If an OS is not secure enough to be put on the big, bad, internet, it should be put behind one that is. Obsolete and/or deficient software is a reason for firewalls and proxies, not for being a menace to the network.
nothing short of killing Steve Jobs and replacing him with a clone (evil clone, of course) is going to get you OS X on a PC.
I think that must be a typo; the Steve Jobs who took millions from Bill gates, killed the Mac clones, and buried their x86 efforts is already the evil clone.
I do this for various testing, including browser testing. With VMWare, I can keep a bunch of old browser combinations around with no extra hardware. Thanks to VMWare's "undoable disk mode", I never have to worry about windows corruption.
And even better, when a colleague needs to do testing, I just copy the virtual disk onto a CD. Much easier than hardware.
It's trivial to implement basic anti-spam measures, such as whitelisting.
Trivial? Please.
I've run my own servers for more than a decade. For me it's been a pain; there are many options, but none of them are no-brainers, and all of them have issues with both false positives and false negatives. To get decent results, I have to run a multi-tier set of stuff and monitor it daily to make sure that it does well.
When grandmothers can do high-quality spam filtering, then you can call it trivial.
Stop complaining about spam and learn to do something against it. Don't leave your doors wide open.
Wide open? Like, say, your telephone? Or your fax machine?
There are laws that restrict the spamming of both of those, because we recognize the problem is a social one, not primarily a technological one. And so should it be with spam.
Re:live with it indeed
on
ISP Chief on Spam
·
· Score: 5, Insightful
the internet is a hostile place, and spam is just one part of it that you have to learn how to fight.
My god! I now get it! And your advice is so appliciable elsewhere in life!
Those people complaining about crime in urban areas? They should just shut up.
People starving to death in Africa because warlords, corrupt governments, and civil war make it impossible to grow food? They should just tighten their belts or eat dirt or something. Or maybe fight back by hiring troops to protect their subsistence farms.
And those people in small, unimportant countries that get invaded? Well, that's their mistake. They should have picked a bigger country to live in. Or domed it over or something.
Yep! The world is a hostile place, and people should learn how to deal with it instead of whining about things like laws and governments and human rights.
But this new file does not have the history of the old file,
It does if you add it (or automate adding it with a simple cvs-rename script). However, it's not clear that that matters much.
Doesn't matter much to whom? To you? Then fine, you can keep using CVS; we'll tell the SCCS Police to make an exception for you.
Or are you saying that cross-rename history tracking doesn't matter for all developer everywhere? In which case, I'd love to hear more about how you checked with them. I must have been out when you called.
CVS, by comparison, is only accessed through the command-line client, so cvs gui clients have to execute the cvs binary and then parse the output, which as you certainly can imagine, is cumbersome.
Anybody who doubts this should try reading the source code to cvs2cl. All it does is build a CHANGELOG file based on the developer comments at checkin, so it should be pretty straightforward, right?
Not nearly. I wanted to make some other CVS reports; when I looked at all the rigamarole that cvs2cl has to go through, I just gave up. With enough time my brain could have handled it, but my stomach never would have.
cvs is way better than no version control. agreed. hell, PVCS and Source Offsite (the two worst version control systems I've ever used) are still way better than no version control.
On a project with more than two developers, quitting to work the fryer at McDonald's is way better than no version control.
Sitting in the same room with my team gives me a great deal of information about the state of the project for free. Getting the same info by telephone or email is much, much harder.
It's not that bad, and I speak as someone who develops software with a distributed team (all of us work from home).
I've done both, and I agree it's possible to develop in a distributed way. But working apart, you only get information on what people choose to say.
In person, you get a lot of valuable information that people don't say. An IM that says "Sure, I'll meet the delivery date," is one thing; being able to watch their eyes when they say it is another. To say nothing of being able to tell whether the guy who hasn't said anything in a while is working hard or just in a panic.
well, the goal is to make sure everybody has all of the equipment they need and everything else is just bits on the wire.
It's a good goal, but converting to bits is hard. And until we all get jacks in the backs of our skulls; some things just won't convert. For example, having a bunch of people doing joint design by moving around CRC cards has a compelling presence that a screen and a mouse just can't match.
So again, I agree that you can develop that way when you have to. But physical presence (and its incrased bandwidth) makes it possible to go faster.
Slashdot Mirror
IMHO if QA cannot keep track of the big picture they fail as QA, because that is just an important part of their job. On the other hand perhaps extreme programming should involve relatively more QA people than 'regular' development methods.
On an XP project, much more QA work certainly gets done than on your average project. One important component of XP are the customer tests, which are automated tests that are used to decide whether or not programmers are done with a particular feature.
Whether there are special QA people who write those tests is a local decision, but good QA people have the right orientation to write really good customer tests.
In fact, a sign of a well-run WebObjects project is that for the first week or two, most of the developers are sitting on their hands or taking long lunches or reading Slashdot. During this time, however, the senior person or two is taking the time to get the underlying data object model right. Only when that is solid does the manager unleash the rest of the troops.
Or not.
Many people use EOF with Agile methods, which generally treat design as something that should be done on a just-in-time basis, rather than in a big up-front spurt. Indeed, EOF works even better with Agile projects than with traditional once, as it makes continuous schema evolution much easier.
Whether it's a schema change or a data change, a change like that mid-way through development is a serious decision, and shouldn't be undertaken lightly.
That's one way to develop.
Or, instead, you could assume that change is a given and tune your development process for that.
The DBA and developers need to work together to work out an ideal schema. Ideally, it's msotly worked out *before* any coding is done. DB objects should not be done on the fly in msot cases.
Yes, ideally all requirements are identified, and then all the design is done, and then all of the code is written. Ideally. And ideally, you could remove the backspace key from they keyboard.
Alas, most of us don't get to code in an ideal world. The premise behind the various Agile methods (Extreme Programming, Crystal, Scrum, FDD, etc.) is that since the world isn't ideal, we might as well pick development methods that are tuned for the world we live in.
Interesting notion, eh?
However, beyond cleaning duplication, keep the SQL near where it is used. [...] However, a more balanced approach is the use the full power the DBMS rather than re-invent it in your application. [...] Thus, either get an OODBMS, or relax the OO design to not duplicate and fight with the RDB and query languages.
I agree that OO and relational thinking are at odds, and that mixing them produces poor results. But if you do good OO design, then the kind of database you use shouldn't be a big issue.
The trick is to put all your persistence logic in one tier of the code. I have one app that will happily use several different backing stores (java serialization, XML files, and SQL storage) at the change of a config line. I could easily add code to use an OO database or an LDAP database.
As long as you design that way, there's very little "fighting with the RDB" to do.
Sometimes I think many OO'ers are motivated by a desire for control, and that is why they would rather reinvent the DB rather than use an existing one. But that is anti-reuse IMO.
Just because you have a database that can do something doesn't mean that you should do it there.
Java, for example, has handy built-in stuff for indexing, joins, filtering, and multi-user contention management. I can happily reuse that, remaining database neutral. Better, most outfits have many more programmers than DBAs; if the logic is in the code rather than the database, I have higher development concurrency and a better truck factor.
Reuse is swell, but as a developer my responsibility is to efficiently deliver good software and keep it up over the long term. RDBs are one tool I'll use to achieve this, but only when they deliver the best business value.
What I really am not crazy about in the article is that it fails to realize that databases live on.
You're close, but you're not quite there yet.
What really should live on is the data, not a particular database or a particular schema. The reasons that applications have to come and go is that they aren't being maintained properly. And one of the big brakes on proper refactoring is database schemas that aren't allowed to change.
If you force your database schemas to evolve along with the application (which in turn is forced to evolve along with your business) then everybody wins. Well, everybody except the Oracle marketroid trying to sell you yet more magic bullets.
For procedural code, you are very right. For object-oriented code, though, relational databases are dangerous. Why?
- One problem is that rectangular tables don't map particularly well to hierachies of objects. This results in either distorted OO models or database layouts that look weird to DBAs (and are therefore hard to optimize).
- Another big problem is that they encourage procedural thinking. There is an awful lot of Java code out there that isn't in any sense object oriented; it is so procedural that it might as well be written in COBOL.
- A third is that they encourage leakage between layers. I don't know how much code I've seen where SQL is scattered fucking everywhere, rather than isolated to a persistence tier. Sure, you can say that programmers shouldn't do that, but when faced with a deadline, an awful lot of developers will cough up some SQL hairball rather than fixing the underlying design issue.
- A fourth is that since the schema duplicates information in your code, this acts as a brake on refactoring. If you use a Martin Fowler's tricks for keeping the database in sync (or if you use a good O/R mapper) you can survive this, but it's still a pain.
- And a fifth is that once the database exists, no matter how much the original designers warn against it, people start using the database as an integration layer. Suddenly 14 different apps are munging the same data, making it impossible to change the schema, and nearly as hard to track down a bug. The whole point of OO programming is that data should always be wrapped by the code that goes with it.
- But my biggest gripe about them is that for 90% of the OO apps out there, an SQL engine just isn't necessary, and only serves to slow things at development and again at runtime.
That's not to say that SQL databases aren't sometimes useful, just that they aren't a magic bullet, and they lead an awful lot of people astray.For those OO developers out there, check out Prevayler. As long as your dataset fits in RAM (and really, how much does RAM cost these days?) you can simplify your code and improve performance by thousands of times.
Even for those who can't use something like Prevayler because the dataset is too large, it's a valuable thought exercise to demonstrate that databases need not be objects of worship.
The stats on those watches look pretty sad. The ones mentioned at the top of this article can supposedly 0.00001mSv/h. The ones at pro-resources.net bottom out at 0.1 mSv/h.
Since background radiation appears to be circa 0.0002 mSv/h, the watch at pro-resources.net apparently will only detect levels 500x normal. They should just get rid of the digital display and just show RARE, MEDIUM, or WELL DONE.
It's very close to, "Do all the analysis, do all the design (down to the level of specifying subroutines), do a little estimating on top of that, and you're done."
Agreed. What I meant is that it's a step away from running a project on bullshit. Eventually, he'll probably realize that there's no good reason to do the detailed design for next year's features before you start next week's features. Then he can take a hint from the just-in-time manufacturing industry and move towards just-in-time design.
XP would say Big Design Up Front doesn't work, but the Planning Game (with "user story" cards as you describe) does. I understand how that works for a single iteration, but not how well it works for a substantial (more than ten staff years) project.
You can think of XP as self-similar across time scales. The basic behaviors (planning, designing, coding, testing, refactoring, integrating, getting feedback) should happen more or less continuously, even on the scale of an individual hour.
So a a release planning meeting (which might happen every 1-3 months) look a lot like an iteration planning meeting (which happens every 1-3 weeks). Which in turn looks a lot like what happens with an individual task. The granularity gets smaller, but it feels very similar.
Or another way to look at it is that after the first iteration is done, an XP project is in maintenance mode. Ergo, you could say that the main difference between a 10-person, 3-month XP project and a 10-person, 3-year one is that the latter is just longer. This means you have more (more releases, more tests, more code, more confidence in estimating, more changes in requirements), but it's essentially the same thing.
Does that help make it clearer?
Yep yep, I think we're in agreeance.
Sorry, that's not allowed on Slashdot. Could you two find some other misunderstanding to argue about?
As consumers, it isn't our responsibility and it isn't possible for us to make sure the businesses we consume from are "viable". As users of open source software, it isn't our responsibility and it isn't possible for us to make sure that an opensource business remains "viable".
Now substitute "employers" for "consumers" and "employees" for "businesses". Still like the way it sounds?
This has a bunch of good advice. Joel is about 50% of the way to inventing Extreme Programming (or yet another Agile methodology) on his own.
The things I'd change:
Chances are, debugging took from 100% - 200% of the time it took to write the code in the first place. This has to be a line item in the schedule, and it will probably be the largest line item.
Sweet jesus! Spending this much time debugging is a bad sign. If you're going to be spending 50-66% of programming time on something, then spend it on automated tests. The best way is to write them before the code, and not in a big lump, either. Write one little test, then write the code to make it pass.
If you spend the time on automated tests instead of debugging, then you won't just finish with a solid program; you'll also end up with a giant suite of tests that makes sure you never break anything.
Put integration time into the schedule.
Sure, putting integration time is better than the typical practice where everybody covers their ears and shouts, "la-la-la-la" when somebody brings this up.
But better still is to make sure that integration happens all the time. It's perfectly possible to check in code at least daily (I check in on average every 20 minutes or so) and to have shippable versions at least once a week.
Really good cooks clean up as they work, so they kitchen is always in pretty good shape. Programmers can learn from this.
The standard format I use for schedules is so simple you can memorize it. You start with just seven columns...
It can be simpler. The Extreme Programming style is to write the name of each feature on a card. Each card is given an estimate of 1, 2, or 3 points; that number is written on one corner of the card. Points are arbitrary, but the units should work out so that a team can do 5-20 points every (generally one-week) iteration. Cards that are bigger than 3 points are torn up; new cards are written that break the big feature down into lots of little ones.
Then the team does an iteration. However many points they get done, that's this week's "velocity".
Which cards to do first? Well, that's a business question, not a technical one. Ergo, the business people should put the cards in order by business value, and programmers should just take 'em off the top.
When do you release? Well, that's a business decision, too. I like putting special colored marker cards in the pile called "release 1", "release 2", etc. The business people can put those where they want.
What's the schedule? When somebody asks, hand them the cards, tell them your current velocity, and let them count their way down the stack to whatever point they are interested in. If they don't like the answer, tell them they are welcome to a) hire more staff, or b) rearrange the cards until they get an answer they like better.
This sounds glib, but it works. I recently got called into a project, already late, where a client handed me a vague 1-page spec for a subsystem and said, "You can have all this done in 5 weeks, right?"
Rather than laughing, I led him through the put-it-on-cards exercise and started working. In the end, we shipped on time, but with only half the original features that he asked for. But since he made all the choices about what to work on when, he wasn't pissed, he was delighted!
if you found the job yourself and was told to go to a 'body shop' to front-end you, you are really bringing the business to the body shop and you should know that the body shop should take about 23% of your income.
I used the shell-company-for-hire ZeroChaos for six months or so last year and was quite happy with them. The employer paid the fee on that one, but my recollection was that ZeroChaos charges a flat $300 per month.
You still have to pay all the various taxes that you would as an independent, but that's still better than 23%. And ZeroChaos also would let you buy benefits (including health insurance and a 401k) through them, which saves some hassle.
The idea behind the French 35-hr week was that if people had to work fewer hours, companies would have to take on more people to do the same work.
Economists call this the lump-of-labor fallacy.
To a naive manager, this sounds appealing. For her salary budget, she has increased productivity by 25-50%!
But this is mainly proof that she isn't measuring productivity. If she were, she'd discover that compulsory overtime doesn't buy her anything in the long term, and probably hurts her. The studies I've looked at (see McConnell's "Rapid Development" for references to good research on the topic) suggest that if you make people spend that much time in the office, they spend a lot of it on doing things other than work.
And if they are programmers, it's even worse. When pressured to go faster, they skip testing, don't polish their code, and ignore big issues until "later". When programmers are tired, they make more mistakes. But since they are testing and polishing less, they find those mistakes later or not at all.
This pushes software projects into a downward spiral: increased bug counts and increased time-per-bug yield slipped schedules. Slipped schedules create more time pressure. More time pressure creates buggier, messier code. Eventually, everything blows up, but generally after the manager who created the problem has moved on.
The solution: taking the time to do it right is the fastest way to get it done:
That last one is especially important. Now that I measure my own productivity, I've discovered that it's better to stop coding when I get tired; otherwise I start making mistakes that cost me later. Then when your boss says, "Everybody must work 60 hours a week until the product ships!" you can say, "What effect do you think that will have on productivity? And if it turns out that 40-hour weeks are the fastest way to get things done, will you go back to them?"
There are surprisingly recent OSes that stil can't limit relaying to specific hosts; it's all (open) or nothing (closed).
If an OS is not secure enough to be put on the big, bad, internet, it should be put behind one that is. Obsolete and/or deficient software is a reason for firewalls and proxies, not for being a menace to the network.
nothing short of killing Steve Jobs and replacing him with a clone (evil clone, of course) is going to get you OS X on a PC.
I think that must be a typo; the Steve Jobs who took millions from Bill gates, killed the Mac clones, and buried their x86 efforts is already the evil clone.
I do this for various testing, including browser testing. With VMWare, I can keep a bunch of old browser combinations around with no extra hardware. Thanks to VMWare's "undoable disk mode", I never have to worry about windows corruption.
And even better, when a colleague needs to do testing, I just copy the virtual disk onto a CD. Much easier than hardware.
I'm still trying to come up with a good reason to replace Wife 1.0. All the newer models look so much cooler.
Sorry, the newer models want more RAM than you can provide.
It's trivial to implement basic anti-spam measures, such as whitelisting.
Trivial? Please.
I've run my own servers for more than a decade. For me it's been a pain; there are many options, but none of them are no-brainers, and all of them have issues with both false positives and false negatives. To get decent results, I have to run a multi-tier set of stuff and monitor it daily to make sure that it does well.
When grandmothers can do high-quality spam filtering, then you can call it trivial.
Stop complaining about spam and learn to do something against it. Don't leave your doors wide open.
Wide open? Like, say, your telephone? Or your fax machine?
There are laws that restrict the spamming of both of those, because we recognize the problem is a social one, not primarily a technological one. And so should it be with spam.
the internet is a hostile place, and spam is just one part of it that you have to learn how to fight.
My god! I now get it! And your advice is so appliciable elsewhere in life!
Those people complaining about crime in urban areas? They should just shut up.
People starving to death in Africa because warlords, corrupt governments, and civil war make it impossible to grow food? They should just tighten their belts or eat dirt or something. Or maybe fight back by hiring troops to protect their subsistence farms.
And those people in small, unimportant countries that get invaded? Well, that's their mistake. They should have picked a bigger country to live in. Or domed it over or something.
Yep! The world is a hostile place, and people should learn how to deal with it instead of whining about things like laws and governments and human rights.
Doesn't matter much to whom? To you? Then fine, you can keep using CVS; we'll tell the SCCS Police to make an exception for you.
Or are you saying that cross-rename history tracking doesn't matter for all developer everywhere? In which case, I'd love to hear more about how you checked with them. I must have been out when you called.
CVS, by comparison, is only accessed through the command-line client, so cvs gui clients have to execute the cvs binary and then parse the output, which as you certainly can imagine, is cumbersome.
Anybody who doubts this should try reading the source code to cvs2cl. All it does is build a CHANGELOG file based on the developer comments at checkin, so it should be pretty straightforward, right?
Not nearly. I wanted to make some other CVS reports; when I looked at all the rigamarole that cvs2cl has to go through, I just gave up. With enough time my brain could have handled it, but my stomach never would have.
cvs is way better than no version control. agreed. hell, PVCS and Source Offsite (the two worst version control systems I've ever used) are still way better than no version control.
On a project with more than two developers, quitting to work the fryer at McDonald's is way better than no version control.
I've done both, and I agree it's possible to develop in a distributed way. But working apart, you only get information on what people choose to say.
In person, you get a lot of valuable information that people don't say. An IM that says "Sure, I'll meet the delivery date," is one thing; being able to watch their eyes when they say it is another. To say nothing of being able to tell whether the guy who hasn't said anything in a while is working hard or just in a panic.
well, the goal is to make sure everybody has all of the equipment they need and everything else is just bits on the wire.
It's a good goal, but converting to bits is hard. And until we all get jacks in the backs of our skulls; some things just won't convert. For example, having a bunch of people doing joint design by moving around CRC cards has a compelling presence that a screen and a mouse just can't match.
So again, I agree that you can develop that way when you have to. But physical presence (and its incrased bandwidth) makes it possible to go faster.
A helpful site is the EFF-affilliated Chilling Effects.