It does sound as if we're mostly saying the same things, but I never saw them used consistently before I started with inception, elaboration, construction, transition from RUP + test first, 2 week iterations, user stories, and scrum from agile.
Regarding defining APIs - I love it when you can define an API early, but in my experience that only happens with very simple APIs, and even then, you end up changing it as you go along. I haven't done this when trying to coordinate between groups, but it seems to me that defining the API for one feature at a time (that both teams work on at the same time) would lead to less churn in the API and fewer failed expectations as you move on through the project.
Um, Huffman is an algorithm in which you assign each token you want to encode a place in a binary tree based on how often the token occurs in the data you want to encode. Items are placed in the tree so that, from the root, you navigate through n bits where 1/2^n is the approximate frequency with which the token occurs in the data. Thus, an item which occurs every other token in your data gets placed to require only one bit.
It is a very efficient compression mechanism if you choose the right tokens. You can get ~20% compression on normal english text using each byte as a token.
It is you who has no clue what you're talking about. I don't know if you're profoundly stupid (and apparently incapable of using google, to boot) and sincere, or just a moderately stupid troll.
I have 11 years of experience, and I've been on projects with processes ranging anywhere from waterfall to no plan to XP to agile + some RUP. Agile + some RUP is by far the most consistent way I've seen to produce a quality product, keep focused on doing the right thing day to day, and end up somewhere that your users are happy.
I never said don't plan - gathering user stories is a process of documenting what your users want. Deciding which ones have the most risk and doing them first is planning the order of implementation and mitigating risk.
If you're planning an entire API before you write code, you're building a plan that can't succeed unless you're very lucky or the system is very, very simple. If you code according to user stories you have a clear plan of what you're doing at all steps, and what's more you have a usable product all the way along - at each step it must do all the things the user said they wanted in the users stories that you've done so far. By focusing on what the users want, you produce something as early as possible on which they can give feedback. By not designing details until you're doing the part that actually depends on those details (you still do design; you just design the part for the user stories you're working on in the current 2 week iteration), you ensure that you're not designing a screw when you need a nail.
Requirements on any significant project are never clear. Never. Ever. No one can write a document that eliminates all ambiguity in a 200,000 loc program and contains no logical inconsistencies. No one can read such a document and recognize all ambiguities and logical inconsistencies. So write an overview of all of the features, and then nail down details when you are ready to build a feature based on them, and not before.
Yeah, I should have been more careful... full RUP is way too much. However, I found that once I understood what Inception, Elaboration, Construction and Transition meant, following those broad steps, along with general agile practices, really made a difference in my project success rate.
So are you against using the terms from Design Patterns, too?
The words I'm using there have well-defined meanings that can't be otherwise expressed without using a paragraph (or multiple pages) instead of one word. If you are a software developer, and what I wrote there looks like gibberish, it really would be worth your time to look them up. Doing those things helps.
I am a software developer, not a manager. I have no interest in doing management or in people who throw around terms like 'paradigm shift', 'actualizing', etc. I do low level work with bit twiddling, work mostly through a unix command line, and I can implement a udp packet processor, huffman encryption algorithm, device driver interface code or a J2EE web app. I'm not aiming for the maximum buzzword concentration; it's just that I've worked under waterfall development processes (do analysis, then design, then coding, then testing) and I've worked under agile processes, and there is just a huge difference in how well you stay on target, time to delivery, and your ability to track progress.
If you're designing spec docs and then coding to them, you're doing the wrong things. I wouldn't apply for such a job.
Rational Unified Process really is the way to go. Waterfall development processes suck to work under and don't perform. Divide a project into clear "user stories", do the risky ones first, and use agile methods (planning poker, team velocity, etc) to estimate time to completion.
You can't know precisely what you want to do until you've tried some of it, all the way through down to coding an example. Trying to design complete spec docs and then coding to them only makes sense if you have built an example system first, and even then you should expect to have to make updates as you learn new things.
It's possible you know about cryptography, but you don't seem to know much about networking... how exactly do we check your ip address?
That said, I don't know anything about CBC and I expect your point is 100% correct. It's just painful to see such a statement from someone purporting to inform me about computer related information.
I use loop-aes when I want an encrypted drive. Setting it up the first time sure is a pain, though.
Mitochondrial DNA is the DNA in mitochondria, organelles that live in all the cells in your body. Mitochondria reproduce asexually, separately from the rest of your cell. The mitochondria in your body come from your mother (the egg cell from which you came had mitochondria from your mother, and they reproduced as you gained new cells).
Since they reproduce asexually, your mitochondria should be identical to those of your mother, barring mutation. This is what lets them trace lineages so well with mitochondrial DNA (there's no intermixing of DNA from your mother & father's genes), and also lets them make some statistical guesses as to when two lineages separated - by measuring how much mutative drift there is between the two sets of mitochondrial DNA.
OK, the subject line is meant to be inflammatory, but hear me out. What I have to say really mostly just regards the presidency, not members of congress or local government.
I do not consider it a democracy when some closed, oligarchical, plutarchical process selects the list of people who may become president. So what if you get a vote, when your vote is between the lesser of two great evils? Name the last president that wasn't the supported candidate by either the Republican or Democratic party. Now explain to me how the process for choosing those 4 or 5 people who are Democratic or Republican candidates is democratic.
Explain to me how someone who falls outside the "platform" one of those two parties presents can become president.
Explain to me how someone without the backing of billionaires can become president.
Of course, I tend to have a total lack of respect for members of the House, and they *are* elected democratically, so arguing whether or not our electoral process for the president is democratic or not may be a moot point.
Excellent point... will we one day find ourselves telling the cashier to wait just another minute or two to ring that up while the effects of the lawsuit we just heard about on the radio filter through to the shelf prices?
As I recall, Microsoft has never been near the top on a per-year basis, so they have no chance of being at the top overall.
I have no opinion about whether MS is near the top of the list by number of patents held, but your logic doesn't hold water. They could easily be #15 in the list each year, and yet be the top in the list overall. All that is required is that #s 1-14 (everyone above them) to change every year. So if MS is granted half as many patents as the #1 patent grantee each year for 10 years, but everyone above MS in that annual list changes each year, MS can easily be #1 over the 10 year period.
I'm not sure about its applicability to business accounting, but gnucash works fine for my personal accounting. I had a couple of user interface issues, but once I worked them out it has done the job for me.
Here are my notes about the issues: You *can* get a report of the total activity in an account in a time period, it's just done in a weird way. You select the report (I think it's account summary). It will instantly do the report, with no choices about the dates. *But* then you can click the Options button on the toolbar and customize it to a date period. This is something that belongs on their FAQ IMO.
The other issue was that there is no way to assign a category to a bunch of transactions at once. That's still true, but you can tab from one field to another to enter data, and it will auto-complete category names if you type them in the right way, and you can hit enter to save your changes instead of having to click another row and then click yes on a pop-up.
Kind of funny how nonsensical arguments don't get modded up like the sensible arguments. Why are people such bigots?
Now, I'm not saying that religion is bunk. I *am* saying that you shouldn't give an argument equal consideration just because it is different. One of the points of this whole big debate about ID vs. evolution is that we shouldn't even be talking about ID! It doesn't give predictions, it doesn't explain anything any deeper than "that's just the way it is" - in short, it's not scientific. At all. It shouldn't even be mentioned in the same breath as evolution, which can predict what fossils you'll find at a particular layer in the earth, and how at least some of the diversity of life we see can be directly explained using processes that we can observe happening, repeatably.
So, if you want to tell me that religion is good because it provides meaning in people's lives, and you can show me how religious people are happier/more productive/more caring than other people, great - I want to hear about it. If you want to tell me I'm a bigot because I don't give equal weight to every harebrained unsupported argument anyone gives, then I guess in your eyes I'll always be a bigot.
until you measure one. Firstly, for quantum entanglement to be there, both photons must have come from a single event, like an electron-positron collision. They come out of that event with no particular polarization, but rather a quantum superposition of polarizations. This is evidenced by the fact that they have a 50-50 chance of passing through any polarization filter, regardless of its orientation.
However, once one of them *has* passed through a polarization filter, the other one must have a polarization of 90 degrees of from the other. So if two people distant from one another have two filters set 90 degrees from each other, and if one photon of an entangled pair passes through one filter, the other must pass through the other filter.
I guess someone's going to have to fill me in on how large a 12,000 cubic meter balloon appears at 24 kilometers..
This is an easy one... your approximation of the sides is OK, but I'll use the volume of a sphere (4/3 * pi * r ^ 3 =~ 4.5 * r^3), so it's about 12000/4.5 =~ 3000, then take the cube root - about 14 meters radius. Now, the visual size of it is a simple proportion. If you want to know how big it will look at 10 meters (across the street), then just figure the proportion from 24 km to 10 m, which is 24000 / 10 = 2400, so at 24 km away it will look like an object 1/2400th its size across the street. 14/2400 =~ 1/170, so it will look like something 1/170th of a meter across the street. A meter is about 40 inches, so 40/170 = less than 1/4 of an inch. Since we were dealing with radius, it's 1/2 an inch in diameter.
These balloons will look like something 1/2 inch across will look from across the street. They'll be difficult to see at all.
Hmm, well, I have a BS in Physics and Mathematics, double major, so I'm not just assuming "there must be an answer, and someone smarter than me will know it". If you were as smart as you seem to think, you would realize that looking in on a problem from an essentially layman point of view (which both you and I have) doesn't give you the vantage point to argue what complex engineering processes can't do. Please note that your argument about bond strength is a red herring - I never asserted we would figure out a way to make the individual bonds stronger.
Basically what we have is a difference of attitude. I see "we have the engineering figured out for using 65 GPa ribbons for a space elevator, and we can produce material now that could almost theoretically have that strength, and in theory we could produce materials almost twice as strong" and I think, this is something that needs research. I am not claiming that 10 years and $100 billion will build a space elevator - I'm claiming that it could put us in a position to know how to build a space elevator, so getting the real funding becomes politically feasible.
You see the same statements, and throw up your hands saying we can't do it. Your arguments that we can't do it are pretty damn weak...
you don't even seem to be arguing that we can't do it, just that it would be expensive, once we find, say, 30% tougher nanotubes and ways to composite them into ribbons 70% as strong as the tubes are individually
you assume that we can never do better than our current models of the chemistry and engineering demonstrate. Remember the 9.6kbaud "physical limits" on modems?
your position seems to be that we've achieved almost all we will achieve with a technology that we didn't even know existed 15 years ago
So your position is that we could almost do it with the materials we have now, on a 15 year old technology, if we had the right compositing process, but that it's ludicrous to think that we could actually do it with 10 more years of research focused on improving strength of individual tubes and processes for producing ribbons?
Comparing this to alchemists' dreams of lead to gold is beyond laughable. Assuming that you know more than the researchers dedicating themselves to this research is ridiculous. Assuming science and engineering will go backward rather than forward is demonstrably false. Asserting a strawman argument about bond strength is a red herring. And repeated commands to "deal" (by which you mean adopt your pessimist philosophy) are obnoxious.
The Wikipedia article says otherwise... it says that 65 GPa - 120 GPa are the expected required strengths. And it says that 63 GPa nanotubes have been created, and 120 GPa are theoretically possible.
It certainly sounds to me as if it's well within the realm of possibility, and that's with no fundamentally new discoveries. The foolish assumption would be that 10 years of research and $100 billion would turn up nothing fundamentally new.
The US could do with some possession by the spirit of Thomas Edison. He saw things we needed, that were obtainable with years of work from the current technology, and he busted his ass to make them happen. It could be done again. Not everything has to be laid out with every piece pre-discovered before we set out to build something. Where would we be if he had said, "Well, hair doesn't work, and copper wire doesn't work. I guess you can't build a light bulb."?
I have found that using a very fine grained task work method keeps me in that "last 4 hours" mindset all the time.
I have heard it explained as Agile, and also as XP, but here are the bits that I think are really important:
* break down the whole project into user stories: the complete list of stuff the user gives a shit about, in the form of little one or two sentence stories about what the user does/the results he expects
* estimate the time to implement the user stories and rank them by risk (high, medium, or low). The risk is how likely it is to take significantly longer than you estimated to do it. Sometimes something could take 2 days, or 2 weeks, depending on whether something goes wrong. Estimate in team days.
* pick a list of 2 weeks worth of user stories. Break them down into tasks. The vast, vast majority of tasks should be 2 days or less of work; break 'em up if they're more. The 2 week period is called an iteration.
* every single day, meet with everyone on the team and tell what tasks you finished since the last meeting, what tasks you're working on, and what you plan to do tomorrow. Also if you face any roadblocks. This meeting is your "last 4 hours" mentality. This meeting should take less than 20 minutes.
There's lots more, but basically this is a combination of Rational Unified Process, XP, and Agile. In my fairly considerable experience doing software development, it kicks ass. It is not only more productive, it is more fun.
BTW, estimation should be done using planning poker... everyone on the team discusses the scope of the user story and what new things have to be done to accomplish it, estimates in team days on a hidden card, then all show their card at once. Argue until you all agree. If the estimate is more than 5 team days, break up the user story.
Slashdot Mirror
It does sound as if we're mostly saying the same things, but I never saw them used consistently before I started with inception, elaboration, construction, transition from RUP + test first, 2 week iterations, user stories, and scrum from agile.
Regarding defining APIs - I love it when you can define an API early, but in my experience that only happens with very simple APIs, and even then, you end up changing it as you go along. I haven't done this when trying to coordinate between groups, but it seems to me that defining the API for one feature at a time (that both teams work on at the same time) would lead to less churn in the API and fewer failed expectations as you move on through the project.
Um, Huffman is an algorithm in which you assign each token you want to encode a place in a binary tree based on how often the token occurs in the data you want to encode. Items are placed in the tree so that, from the root, you navigate through n bits where 1/2^n is the approximate frequency with which the token occurs in the data. Thus, an item which occurs every other token in your data gets placed to require only one bit.
It is a very efficient compression mechanism if you choose the right tokens. You can get ~20% compression on normal english text using each byte as a token.
It is you who has no clue what you're talking about. I don't know if you're profoundly stupid (and apparently incapable of using google, to boot) and sincere, or just a moderately stupid troll.
I have 11 years of experience, and I've been on projects with processes ranging anywhere from waterfall to no plan to XP to agile + some RUP. Agile + some RUP is by far the most consistent way I've seen to produce a quality product, keep focused on doing the right thing day to day, and end up somewhere that your users are happy.
I never said don't plan - gathering user stories is a process of documenting what your users want. Deciding which ones have the most risk and doing them first is planning the order of implementation and mitigating risk.
If you're planning an entire API before you write code, you're building a plan that can't succeed unless you're very lucky or the system is very, very simple. If you code according to user stories you have a clear plan of what you're doing at all steps, and what's more you have a usable product all the way along - at each step it must do all the things the user said they wanted in the users stories that you've done so far. By focusing on what the users want, you produce something as early as possible on which they can give feedback. By not designing details until you're doing the part that actually depends on those details (you still do design; you just design the part for the user stories you're working on in the current 2 week iteration), you ensure that you're not designing a screw when you need a nail.
Requirements on any significant project are never clear. Never. Ever. No one can write a document that eliminates all ambiguity in a 200,000 loc program and contains no logical inconsistencies. No one can read such a document and recognize all ambiguities and logical inconsistencies. So write an overview of all of the features, and then nail down details when you are ready to build a feature based on them, and not before.
Yeah, I should have been more careful... full RUP is way too much. However, I found that once I understood what Inception, Elaboration, Construction and Transition meant, following those broad steps, along with general agile practices, really made a difference in my project success rate.
So are you against using the terms from Design Patterns, too?
The words I'm using there have well-defined meanings that can't be otherwise expressed without using a paragraph (or multiple pages) instead of one word. If you are a software developer, and what I wrote there looks like gibberish, it really would be worth your time to look them up. Doing those things helps.
I am a software developer, not a manager. I have no interest in doing management or in people who throw around terms like 'paradigm shift', 'actualizing', etc. I do low level work with bit twiddling, work mostly through a unix command line, and I can implement a udp packet processor, huffman encryption algorithm, device driver interface code or a J2EE web app. I'm not aiming for the maximum buzzword concentration; it's just that I've worked under waterfall development processes (do analysis, then design, then coding, then testing) and I've worked under agile processes, and there is just a huge difference in how well you stay on target, time to delivery, and your ability to track progress.
If you're designing spec docs and then coding to them, you're doing the wrong things. I wouldn't apply for such a job.
Rational Unified Process really is the way to go. Waterfall development processes suck to work under and don't perform. Divide a project into clear "user stories", do the risky ones first, and use agile methods (planning poker, team velocity, etc) to estimate time to completion.
You can't know precisely what you want to do until you've tried some of it, all the way through down to coding an example. Trying to design complete spec docs and then coding to them only makes sense if you have built an example system first, and even then you should expect to have to make updates as you learn new things.
See http://projectbootstrap.pbwiki.com/
It's possible you know about cryptography, but you don't seem to know much about networking... how exactly do we check your ip address?
That said, I don't know anything about CBC and I expect your point is 100% correct. It's just painful to see such a statement from someone purporting to inform me about computer related information.
I use loop-aes when I want an encrypted drive. Setting it up the first time sure is a pain, though.
Mitochondrial DNA is the DNA in mitochondria, organelles that live in all the cells in your body. Mitochondria reproduce asexually, separately from the rest of your cell. The mitochondria in your body come from your mother (the egg cell from which you came had mitochondria from your mother, and they reproduced as you gained new cells).
Since they reproduce asexually, your mitochondria should be identical to those of your mother, barring mutation. This is what lets them trace lineages so well with mitochondrial DNA (there's no intermixing of DNA from your mother & father's genes), and also lets them make some statistical guesses as to when two lineages separated - by measuring how much mutative drift there is between the two sets of mitochondrial DNA.
For more information about mitochondria, see the Wikipedia entry: http://en.wikipedia.org/wiki/Mitochondrion
Today's episode of Sesame Street is brought to you by the number 6, and the letters C, G, T, and A.
OK, the subject line is meant to be inflammatory, but hear me out. What I have to say really mostly just regards the presidency, not members of congress or local government.
I do not consider it a democracy when some closed, oligarchical, plutarchical process selects the list of people who may become president. So what if you get a vote, when your vote is between the lesser of two great evils? Name the last president that wasn't the supported candidate by either the Republican or Democratic party. Now explain to me how the process for choosing those 4 or 5 people who are Democratic or Republican candidates is democratic.
Explain to me how someone who falls outside the "platform" one of those two parties presents can become president.
Explain to me how someone without the backing of billionaires can become president.
Of course, I tend to have a total lack of respect for members of the House, and they *are* elected democratically, so arguing whether or not our electoral process for the president is democratic or not may be a moot point.
Excellent point... will we one day find ourselves telling the cashier to wait just another minute or two to ring that up while the effects of the lawsuit we just heard about on the radio filter through to the shelf prices?
As I recall, Microsoft has never been near the top on a per-year basis, so they have no chance of being at the top overall.
I have no opinion about whether MS is near the top of the list by number of patents held, but your logic doesn't hold water. They could easily be #15 in the list each year, and yet be the top in the list overall. All that is required is that #s 1-14 (everyone above them) to change every year. So if MS is granted half as many patents as the #1 patent grantee each year for 10 years, but everyone above MS in that annual list changes each year, MS can easily be #1 over the 10 year period.
I'm not sure about its applicability to business accounting, but gnucash works fine for my personal accounting. I had a couple of user interface issues, but once I worked them out it has done the job for me.
Here are my notes about the issues:
You *can* get a report of the total activity in an account in a time period, it's just done in a weird way. You select the report (I think it's account summary). It will instantly do the report, with no choices about the dates. *But* then you can click the Options button on the toolbar and customize it to a date period. This is something that belongs on their FAQ IMO.
The other issue was that there is no way to assign a category to a bunch of transactions at once. That's still true, but you can tab from one field to another to enter data, and it will auto-complete category names if you type them in the right way, and you can hit enter to save your changes instead of having to click another row and then click yes on a pop-up.
Kind of funny how nonsensical arguments don't get modded up like the sensible arguments. Why are people such bigots?
Now, I'm not saying that religion is bunk. I *am* saying that you shouldn't give an argument equal consideration just because it is different. One of the points of this whole big debate about ID vs. evolution is that we shouldn't even be talking about ID! It doesn't give predictions, it doesn't explain anything any deeper than "that's just the way it is" - in short, it's not scientific. At all. It shouldn't even be mentioned in the same breath as evolution, which can predict what fossils you'll find at a particular layer in the earth, and how at least some of the diversity of life we see can be directly explained using processes that we can observe happening, repeatably.
So, if you want to tell me that religion is good because it provides meaning in people's lives, and you can show me how religious people are happier/more productive/more caring than other people, great - I want to hear about it. If you want to tell me I'm a bigot because I don't give equal weight to every harebrained unsupported argument anyone gives, then I guess in your eyes I'll always be a bigot.
care to post the link?
until you measure one. Firstly, for quantum entanglement to be there, both photons must have come from a single event, like an electron-positron collision. They come out of that event with no particular polarization, but rather a quantum superposition of polarizations. This is evidenced by the fact that they have a 50-50 chance of passing through any polarization filter, regardless of its orientation.
However, once one of them *has* passed through a polarization filter, the other one must have a polarization of 90 degrees of from the other. So if two people distant from one another have two filters set 90 degrees from each other, and if one photon of an entangled pair passes through one filter, the other must pass through the other filter.
Yeah, your cube root was impressive... the thing that surprised me was that you did the hard part and then stopped.
This is an easy one... your approximation of the sides is OK, but I'll use the volume of a sphere (4/3 * pi * r ^ 3 =~ 4.5 * r^3), so it's about 12000/4.5 =~ 3000, then take the cube root - about 14 meters radius. Now, the visual size of it is a simple proportion. If you want to know how big it will look at 10 meters (across the street), then just figure the proportion from 24 km to 10 m, which is 24000 / 10 = 2400, so at 24 km away it will look like an object 1/2400th its size across the street. 14/2400 =~ 1/170, so it will look like something 1/170th of a meter across the street. A meter is about 40 inches, so 40/170 = less than 1/4 of an inch. Since we were dealing with radius, it's 1/2 an inch in diameter.
These balloons will look like something 1/2 inch across will look from across the street. They'll be difficult to see at all.
Computer science is the art of automating anything that's been refined to a science.
Hacking is a form of computer science.
The GP2X doesn't have wireless! I want wireless (I would actually be perfectly content with 802.11b), then I'm there.
Basically what we have is a difference of attitude. I see "we have the engineering figured out for using 65 GPa ribbons for a space elevator, and we can produce material now that could almost theoretically have that strength, and in theory we could produce materials almost twice as strong" and I think, this is something that needs research. I am not claiming that 10 years and $100 billion will build a space elevator - I'm claiming that it could put us in a position to know how to build a space elevator, so getting the real funding becomes politically feasible.
You see the same statements, and throw up your hands saying we can't do it. Your arguments that we can't do it are pretty damn weak...
So your position is that we could almost do it with the materials we have now, on a 15 year old technology, if we had the right compositing process, but that it's ludicrous to think that we could actually do it with 10 more years of research focused on improving strength of individual tubes and processes for producing ribbons?
Comparing this to alchemists' dreams of lead to gold is beyond laughable. Assuming that you know more than the researchers dedicating themselves to this research is ridiculous. Assuming science and engineering will go backward rather than forward is demonstrably false. Asserting a strawman argument about bond strength is a red herring. And repeated commands to "deal" (by which you mean adopt your pessimist philosophy) are obnoxious.
The Wikipedia article says otherwise... it says that 65 GPa - 120 GPa are the expected required strengths. And it says that 63 GPa nanotubes have been created, and 120 GPa are theoretically possible.
It certainly sounds to me as if it's well within the realm of possibility, and that's with no fundamentally new discoveries. The foolish assumption would be that 10 years of research and $100 billion would turn up nothing fundamentally new.
The US could do with some possession by the spirit of Thomas Edison. He saw things we needed, that were obtainable with years of work from the current technology, and he busted his ass to make them happen. It could be done again. Not everything has to be laid out with every piece pre-discovered before we set out to build something. Where would we be if he had said, "Well, hair doesn't work, and copper wire doesn't work. I guess you can't build a light bulb."?
Um, how can a comment about the consequences of an imaginary machine be insightful in a thread about a real machine?
I'm not ragging on you for making the comment - the comment is perfectly reasonable. What isn't reasonable is the "+4 insightful" I see on it.
But I just can't resist....
Who the fuck cares?
He was *writing and distributing worms* and using his RL name online might have struck him as a bad idea.
Yeah, yeah, offtopic, but I have karma to burn.
I have found that using a very fine grained task work method keeps me in that "last 4 hours" mindset all the time.
I have heard it explained as Agile, and also as XP, but here are the bits that I think are really important:
* break down the whole project into user stories: the complete list of stuff the user gives a shit about, in the form of little one or two sentence stories about what the user does/the results he expects
* estimate the time to implement the user stories and rank them by risk (high, medium, or low). The risk is how likely it is to take significantly longer than you estimated to do it. Sometimes something could take 2 days, or 2 weeks, depending on whether something goes wrong. Estimate in team days.
* pick a list of 2 weeks worth of user stories. Break them down into tasks. The vast, vast majority of tasks should be 2 days or less of work; break 'em up if they're more. The 2 week period is called an iteration.
* every single day, meet with everyone on the team and tell what tasks you finished since the last meeting, what tasks you're working on, and what you plan to do tomorrow. Also if you face any roadblocks. This meeting is your "last 4 hours" mentality. This meeting should take less than 20 minutes.
There's lots more, but basically this is a combination of Rational Unified Process, XP, and Agile. In my fairly considerable experience doing software development, it kicks ass. It is not only more productive, it is more fun.
BTW, estimation should be done using planning poker... everyone on the team discusses the scope of the user story and what new things have to be done to accomplish it, estimates in team days on a hidden card, then all show their card at once. Argue until you all agree. If the estimate is more than 5 team days, break up the user story.
End off-topic rant.