To take a leaf from Star Trek just do what he always did. Say it will take 3 times as long as you think it will, and you will always get half that time to complete it. And if you get it done early you will be rewarded.
I think you left something off at the end. "And if you get it done early, you will be rewarded with even less time for the next project."
For the most part, your ability to give an estimate on a change is a matter of experience. General experience will give you a rough idea of how long it would take to implement some random feature. Specific experience with the system in question will give you a much more refined ability to make an estimate. If you can't make an estimate, or you can only make a rough estimate, be upfront about it. Tell your manager or the customer (if you're the one working directly with the customer) that your estimate is very rough, and try to add as much buffer time as possible. Also, don't get into granular estimates when you can only give a rough SWAG (Some Wild-Ass Guess). If you think it'll take you an hour, say a day. If you think it'll take you a day, say three. If you think it'll take you three days, say a week (experience will tell you how much buffer to add). If you don't have enough experience with the system to make a good estimate, ask your co-workers for help. It's always better to under-promise and over-deliver than the other way around. Besides, while you may end up over-estimating some feature, chances are you also underestimated another one and the extra buffer time you don't need for feature A will be invaluable to finishing feature B.
To help you make better estimates, you should make sure you get a solid set of requirements from your customers. Time should be spent with the customer to determine exactly what it is they want (they may not be able to articulate it clearly), and whether or not there's already a solution they could use if they're only willing to change their process. Avoid telling the customer at that point whether something is "easy" or "hard" (and definitely ignore them when they suggest something will be easy -- they don't know the inner workings of the code, so how will they know if it's hard or easy? Changing a piece of text may look trivial, but may involve a number of external factors such as localization or legal that would turn a 5 minute fix into a two month battle). Take what you've learned, distill it down into a solid set of requirements, and take that back to the customer for sign-off. Once they've signed off, they don't get to change their mind any more for this cycle (however long that may be -- days, weeks, months, or even years, though hopefully not nearly as long as that). Then you get rough estimates from the developers based on their gut feelings and knowledge of the code base, and have them investigate deeper to solidify those estimates. At that point, you have enough to build a schedule, but allow for buffer time! A developer's 8 hour day may not be 8 full hours of coding. It may be 4 hours of coding, two hours of meetings, an hour for lunch, and an hour of "filler" for the cost of task-switching depending on how the coding hours and meeting hours overlap. Based on your experience with past projects, you should have a good idea of how much time per day a dev actually gets to spend on coding and use that to build your schedule. For example, developer estimates are all in 8 hour day increments, but you know from experience that developers average 6 hours per day of productive work. That means a 5 estimated days will actually take 6.7 real days, so use that as your buffering criteria. (BTW, six hours of productive work is actually high. In most cases, it's really closer to 4 or 5.)
Finally, don't forget QA. Just because a developer has confidence that he can implement a specific feature in one hour doesn't mean it won't take QA a week to verify all of the ramifications of that change. You really need to have your QA team working in lock-step with your dev team. Your dev team should write technical specs on the features, and your QA team should estimate impact off of those. The "agile" disciplines that are en vogue lately try to incorporate testing directly into the development process, which is good. However, that means that developers will be in charge of including QA costs on their estimates, which developers are usually bad about doing
I mean heck, if the Wii debuts at $199, you could get it for christmas and afford to give one to your borther/cousin/etc for as much as it would cost to get one Xbox 360 non-core system (you end up needing some kind of hard drive eventually to save your games...).
New math? Wii math? Maybe you need to go pick up Brain Age for NDS and brush up on your skills:). Also, you don't need a $100 hard drive to save your games. You can use a $40-50 memory card instead. And one would assume you'll need the same for a Wii, so I'm leaving that out of my calculations.
The breakdown (ignoring tax:
Xbox 360 Core: $300
Hard drive: $100
Component cable: $30
Wireless controller: $60 (minus $20 resale for the wired controller, giving a $40 differential) -- I may be a little off on this one, having not purchased either a wired or wireless controller separate from the console itself.
Headset: $20
Grand total to make an Xbox Core into an Xbox Premium: $510 ($490 if you sell the original wired controller from the Core for $20)
Xbox 360 Premium: $400
Wii: Rumored price at $250. Your suggested price at $200
For the price of a Core without a hard drive, I could buy 1.25 Wiis. For the price of a Core converted to a Premium, I could buy 2.04 Wiis, but why would I do all of that to a Core when I could buy a Premium instead? For the price of a Premium, I can buy 1.6 Wiis. In other words, I cannot buy 2 Wiis for the price of a Core or the price of a Premium. I could buy 2 Wiis for the price of a Core + everything else, but then I would've just bought a Premium instead. If you use your $200 figure, you still can't get 2 Wiis for the price of one Core, but you could get 2 Wiis for the price of one Premium.
More interesting: For the price of a PS3 ($600) + 3 games ($60 * 3 = $180), I could instead buy an Xbox 360 Premium ($400), a Wii ($250), a Microsoft game ($50), a Wii game ($50?), and still have enough left over to buy a GBA game ($30). Or I could buy a third-party 360 game ($60), a Wii game ($50?), and still have enough left over to buy Halo 2 ($20).
Both Nintendo and Sony had online options in the Xbox/PS2/GC generation, but Xbox Live was the clear winner. Sony's now planning on copying Xbox Live for the PS3, and Nintendo's retro game market looks like it's strongly influenced by Xbox Live's marketplace and Arcade. Nintendo and Sony may get their acts together, but Microsoft has a huge lead (in knowledge, implementation, and mindshare) with Live that will be tough to beat.
In fact, for those of us who don't have 1080i tv's, graphics quality isn't going to matter that much.
I'd rather have a 720p TV than a 1080i (interlacing == flickering == hurts my eyes, and 720p has more usable resolution, as 1080i's vertical resolution in movement is really only 540). A 1080p system is a waste of money right now (check back in ~2 years). And that's why I replaced my old 1080i TV with a new 720p TV last November.
Keep in mind that "graphics quality" involves more than just higher resolution textures. It means more detailed models, more objects on screen at a time, more realistic rendering effects, etc. All of that will be noticeable on a standard-definition TV. Of course, it does still depend on developers using the full power of the system. If a developer just applies higher resolution textures and anti-aliasing to PS2-grade graphics, that's going to suck on any TV (see Gun, several of the sports titles from Xbox 360 launch).
In fact, I think what this race is going to boil down to is number of available games (Wii might actually win this one, taking the ROM distribution into account), and price (nobody I know loves PS exclusive games enough to spend roughly 3x the money on it)
It always boils down to number of available games. I wouldn't count out Xbox Live Arcade just yet, either. And with Sony losing GTA's launch exclusivity, there's one less reason to buy a PS3.
While I'll probably end up buying all three (I have a 360 now, I'm planning on getting a Wii at launch, and I'll pick up a PS3 in 3-4 years when it's affordable), my current plan is to go Wii60.
And hey, if they move what they can to.Net and emulate Windows, then they'll have the flexibility to move to a different processor architecture if they want, without the compatibility problems that Apple is going through with that.
Speaking of Windows, different multi-core processor architectures, Virtual PC, and.NET, have you looked at Xbox 360 lately?
It uses a triple-core PowerPC derivative processor
It's powered by a PPC-ported version of the Xbox operating system, which itself was a customized version of Windows 2000/XP
It runs many Xbox games via emulation at "native" (to the original Xbox's 733MHz/64MB architecture) speed. While I assume that this is purpose-built emulation and not an Xbox 360 port of Virtual PC/Virtual Server, it's not hard to believe that the virtualization and emulation domain knowledge that came with the purchase of Connectix made this possible
It's one of the core components of XNA, which includes support for Managed DirectX (and thus, a port of.NET to Xbox 360)
As much as I love my Xbox 360, I have no illusions of it taking over all (any!) of my general-purpose computing (nor do I expect or want the PS3 to do so, Kutaragi!). However, when you look at the bullet points it's pretty easy to come to the conclusion that Xbox 360 may just be an incubation project for future hardware architectures and operating systems.
What I think is odd about this is that the NT architecture has never really even been fully utilized, at least on the consumer side of Windows. In a lot of respects, NT is a pretty clever system, including highly individualizable security for files, processes, etc. It also supports multiprocessing well, contrary to the implication of the article. Point being, I'm not so sure the solution for Microsoft is to throw out NT and move on to something else (Singularity, or whatever it may be). I would suggest they instead look at the features already in place with NT and look at ways to actually enable and present them in a reasonable way in their consumer OSes.
I think the key point to keep in mind here is not that Microsoft is looking for a successor to Windows, but that these statements came from "a program manager for external research programs in the Microsoft Research group". This is what Mirosoft Research does. They come up with blue-sky ideas like replacing Windows entirely, and then the product groups integrate those ideas into real, shippable products. As an example, the "Drivatar" AI used by Forza Motorsport came directly out of MSR. The researchers had grand plans for the technology (get real motorsport "legends" to generate drivatars based on their driving style, learn from the player as he's playing, etc), while the implementation in Forza was more practical (the main AI was based on pre-release training and didn't learn from watching the player, there were no "professional" drivatars, the player had to actively train his drivatar in specific sessions rather than having it learn while he plays, etc). That's not a bad thing, and it's still a damn sight better than most other racing game AI out there (Gran Turismo, I'm looking at you. Damn retarded bumper car AI...). Researchers are good at coming up with crazy ideas and sample implementations that don't take into account the rest of the system (back to Forza, there's only so much processing available in an Xbox to handle all of the physics and AI, which means that real-time drivatar training wouldn't be feasible). If you know what to look for, you can see many Microsoft Research contributions in shipping products (speech, grammar checking, natural language processing, etc in Office; anti-phishing in the MSN/Windows Live Toolbar and IE7; pretty much the entire backend for MSN/Windows Live Search; and so on), but it's only bits and pieces. Go poke around, look at the many areas of research going on at MSR. Take a look at their sample code. And then remember that when you see a similar but less-grandiose feature 5-10 years from now in a real, shipping product.
Note: I'm neither a Microsoft researcher nor a Forza developer, so all of the information above is what anyone can deduce from the sources I cited.
The other thing I'd like to see Microsoft do is separate out the kernel-level framework (NT system, drivers, etc) from the UI framework, so that it would then be possible to treat those two elements separately, in the same way that Linux has the kernel and X/Window Manager stuff totally separated out.
Microsoft has already done this to a fair extent with Terminal Server. The main thing to keep in mind is that the main bits in kernel space really are drivers, not the UI framework (and even that's changing with Vista). Terminal Server is very much Microsoft's X. Do you remember the "Fast User Switching" feature in Windows XP? Yeah, that's Terminal Server, and what it really means is that every time you use the Windows UI (in XP and 2K3) you're actually interfacing through a local Terminal Server session (just like X!). Of course, TS will have its little differences when running over a network, like not supporting video overlays or 3D acceleration, but in most case
However, if you work in an IT deadzone, what you will find a lot of times in those Geek Squads is very talented *geeks* who are working there as their first IT job because there aren't that many opportunites for IT in their area.
Relocate! If you can't find good work doing what you want (getting paid near minimum wage isn't "good work"), and you're not willing to do something else instead, then it's time to move. If you are such a smart and talented "geek", you should have no problem finding a job elsewhere.
Mining the data for this type of bidder behavior in order to compare its effectiveness versus sniping would probably be difficult, and I see no evidence in the linked article that the researchers studied it. But from my limited perspective, it seems like a great strategy.
The only flaw in your strategy is that it requires the buyer to be willing to also become a seller. Many times, this is not the case. For example, I've only purchased a few items via ebay over the years. I've sniped most of those auctions because they were things that I would like to have but weren't so critical that I would care if I lost, while at the same time I wasn't so invested that I wanted to bid on tens of different auctions. If I win, I get what I wanted. If I lose, I don't. Most importantly, I don't run the risk of winning multiple auctions, having to pay for that merchandise, and then try to flip it. Since I rarely use ebay, it should be obvious that I have low reputation (what I do have is good, but there's not much there) which can hurt sellers. I don't want to spend my time listing the auction and hoping I can sell the item for enough over what I paid that I can at least break even.
For casual users like myself, sniping is the only way to go. Your method requires too much investment, and "normal" bidding will result in bidding wars that could end up costing way more than the item is worth. Sniping from a position where you don't care if you lose Just Works (tm).
And meanwhile ReiserFS on Linux provides much of the functionality today that WinFS only promised for the future.
I've not used ReiserFS (my linux box runs on XFS, for no real reason other than it was the cool thing to do six years ago), but on the face of things I don't think your claim is correct. ReiserFS (or as you linked, Reiser4, since ReiserFS/Reiser3 has ceased development but for critical issues) is a metadata-only journalling filesystem, still based around a directory structure. In other words, it's just like NTFS, though each FS has features the other doesn't (ReiserFS has better fragmentation management, NTFS has integrated encryption, etc). WinFS, on the other hand, is a relational-based filesystem that intended to do away with directory structures entirely (you could still have folders/directories, but they'd be "virtual" -- storage of files was not tied to any specific folder or directory). At the same time, WinFS isn't a "true" filesystem, but another enhancement on top of NTFS.
Why not try an Intel board? Not to be a fanboy or anything but their linux support is good. Intel NICs can't be beat for support and performance either.
One may find it difficult to fit an AMD CPU on an Intel motherboard. Pesky competition.
As the grand-parent said, he had to exchange a motherboard. That means he wasn't intentionally upgrading, thus expecting to continue to use the rest of his hardware (memory, disk, CPU). Were this a system upgrade rather than a replacement of a faulty part then it may be useful to suggest he look at an Intel-based solution. As it is, he obviously already had an AMD CPU and so he needed another motherboard that would work with said CPU.
My guess is because it was a lot easier/cheaper/faster to make Barbie Horse Adventures backwards compatable.
Which is wrong. Or, well, not exactly right. Bigman answered his own (rhetorical?) question correctly already:
This was just a throw-in...meaning that when they made something else backward compatible, this game came along for the ride. They didn't have to do any work to make it happen.
In other words, Barbie Horse Adventure either used the same engine as some other game, or was so technically simple that it just works without any extra hacking. Why they bother to list it on the BC list is beyond me, though. Maybe the 6 year old girl demographic is really important?:)
all 4 years of it? or will they decide that 4 is far to long for the system and knock it down to 3 years? then the one after that would be 2 untill we are buying a new console every single year!:P
Well, the 360 is designed to eventually break-even or even make money, which the Xbox was not. So, Microsoft will not be as pressed to get the Xbox 3/720/Next/whatever out in another 4 years. And if all goes well (poorly, that is) with the PS3, Microsoft will be in a much more comfortable position and not have to fight for first-mover status like they did with the 360.
That said, even during the Xbox's four years, you could visibly see developers making advancements in technology. A good example is Halo vs. Halo 2. Not only did things get shinier/bumpier (adding more detail through bump mapping techniques rather than geometry), they also were able to render in widescreen while the original didn't. If you compare Project: Gotham Racing to PGR 2, you'll see similar changes -- better trackside textures and models, better textures all around, better car models and environment maps, etc. And then compare PGR2 to Forza, and you'll see even more differences (though some are under the covers, such as the 4-wheel independent suspension physics simulation used in Forza, compared to the standard of Pacejka's Magic Formula). It's certainly not as much of an improvement as we saw through the life of the Playstation (compare Final Fantasy VII to Final Fantasy IX), but it's still there and once would expect similar advances on the 360 as developers get used to the technology.
The biggest problem is that the user is expecting bigger worlds with more nice stuff to look at every new game. The problem is creating this huge content.
I know this is Slashdot, so you obviously didn't read the article. Did you even read the summary, though? This bit was quoted in part right there in the summary:
The tessellator in the Xbox 360 GPU is indeed a very powerful piece of hardware, and you're right--most games have yet to take advantage of this. I think you'll see more titles use it in the future. As for procedurally generated worlds, I believe the biggest obstacle to overcome is how to design and build the content for such a system--it can be quite a departure from today's art pipelines. Game studios will figure it out though--it's crucial to generating and delivering ever larger worlds without having to exponentially grow the size of the art team.
Right now, the best example of using procedurally-generated worlds is a third-party bit of middleware "SpeedTree," which was used to generate all the trees in Oblivion, although this was not done on the fly. This cuts down a lot of work for the artists, who then don't have to spend days making dozens and dozens of slightly different tree models. The idea of using on-the-fly procedural synthesis is one that even Microsoft hasn't explored yet.
In other words, Microsoft and third-parties already have ways to procedurally generate textures and models so that an artist doesn't have to toil over "dozens and dozens of slightly different tree models", for example. Adoption of such techniques will only increase as games get ever more complex.
This is just what Will Wright is solving with Spore for example. What is the thing people like more then watching all this content? Making it! Thats why his games let people create it in a smart way instead of the developers/artists.
That's all well and good, but it's a limited approach. The obvious issue is that it works best for PCs, where people have the full power of a PC (and thus developer- and community-provided tools) to build mod content. That's not going to work nearly so well on a console. More importantly, IMHO, is that the developer still has to provide some content to get you going, or most people won't stick around long enough to create their own. Finally, this doesn't necessarily work for all genres. It'll work with Spore because that's a sandbox game. It wouldn't work so well with Half-Life or Halo, because the single-player portions of those are too important (you can get community involvement for multiplayer, but the developers are still going to have to produce huge amounts of high-quality art for the single-player experience).
That is (IMHO) the future of gaming, and hopefully for them, the future of Microsoft gaming.
I disagree. This is part of the future of gaming, but I really hope it's not the whole future. That's like saying blogs are the future of book publishing, or YouTube is the future of movies. It's great to give your users/fans/players a way to contribute back, but unless every game is just another Sims sandbox (boring!), we'll still need the "masters" (as in, professionals who are dedicated to their art, with the resources to produce outstanding work) to provide us with compelling stories, graphics, AI and behaviors, etc. Some of that may be procedurally generated, but at the root of that should always be a professional artist.
Why buy a standalone blu-ray player for a thousand when I can get a PS3 that does the same plus more for 600?
Because integrated devices generally suck. Go back to the PS2 in 2000. Why would you buy a $500 stand-alone DVD player when you can buy a PS2 for $300 that does the same plus more? Because the PS2 was a horrible DVD player. Do you really expect the PS3 to be a great Blu-Ray player?
Of course, that's assuming you buy into Blu-Ray at all, or that you must be an early adopter of the format. Personally, I'm going to wait it out. I may eventually buy a PS3, but it won't be for Blu-Ray. I may eventually buy a HD-DVD or Blu-Ray player, but not until the format war shakes itself out, prices drop to a sane level ($500 or less, preferably $300 or less), and the available library of movies grows. Until then, my $100 upconverting DVD player looks awesome at 720p (via HDMI), as does my Xbox 360 at 720p (component). My TV doesn't do 1080p, because a) 1080p is still too expensive, and b) nothing uses it yet (TV upscale/de-interlace generally sucks, so if I have to do conversion I'd rather it be done at the player level, like an upconverting DVD player).
Emphasis mine... Strange, as I have Splinter Cell: Chaos Theory at home. The only way to get 100% complete on any level is to not kill anybody while still completing all objectives.
All of the Splinter Cell games have been that way. Also, don't forget the Hitman games. While they do allow you the option of running and gunning through the game (nearly impossible in Splinter Cell, impossible in Thief), you can only get Silent Assassin rankings by leaving no trace. That means not killing anybody but your assigned target, nor doing anything suspicious that might alert others, leaving your changes of clothing or guns lieing around, etc. In some cases, this may even extend to as far as closing doors you opened, because finding an open door may alert guards or civilians to your presence
It all boils down to what's "easy", I think. It's not easy to make a fun, compelling game where your entire goal is to accomplish your objectives without ever being seen or heard. It requires exceptional control mechanics, AI, level design, and more. A number of games have tried, and most have failed. It's much easier to do a straight-forward run 'n gun like Doom (though even that is difficult to do well -- Serious Sam is really the best example of fun mindless action).
While the odds are stacked firmly against a poorly written article containing any worthwhile insight, they do come along every now and then. I try not to judge an article solely on its phrasing and grammar, though I'll readily admit it does make me start out with a negative bias. Still, I try to give them the benefit of the doubt by reading what of it I can endure.
Trouble is, you're going to have to read through a lot of painful crap before you find something that justifies this position. For me, if grammar and spelling is so horrible that I can barely make it through the first paragraph (worse, if the first paragraph is of normal length, but a single sentence), I'm going to skip the article. Maybe by doing so I'll miss the cure for cancer, but I'll take that chance.
If someone can't write proper, do us all a favor and run it by someone else that can.
I'm the last guy that should say anything, but I can't help myself. That should be "can't write properly", being an adverb that modifies the verb "write".:)
Language skills going rapidly downhill seems to be rather epidemic of late though. Around here not even the bloody newspapers bother with a basic spellchecker these days. It really shows.
I have a feeling that language skills have always sucked. We're just seeing it more today because it's getting ever easier for non-professionals to write something that has a chance of being read widely. I'm sure if you looked at personal letters from your grandparents' generation, or even your parents', you'd find just as horrible spelling and grammar. I've read old letters between my aunts and my mom from a couple decades ago, and the spelling and grammar is just as bad as it is today. IM/Text-speak crap like "u", "r", "2", etc, hadn't entered the vernacular yet, but common failings like it's/its, their/there/they're, lose/loose, chose/choose, and more are all represented.
I've had the shiny layer on cheap cd-rs stick right to the disc on top of it in a spindle. I'm sure the 100% humidity here doesn't help, though.
Nothing a little ingenuity can't fix. Go buy yourself a roll of parchment paper (silicone-impregnated paper used for high-heat cooking where wax paper would melt or aluminum foil would react with acidic foods, available at grocery stores everywhere). Using a CD as a template (the clear plastic top "disc" of most spindles would be perfect), trace out a number of CD-sized circles, cut them out (a hobby knife or other sharp knife would be best, as it'll be difficult to cut out the centers with scissors), and sandwich them in between each disc. No more sticking!
That's $1.06 per gigabyte RAID5 with hotspare. It doesn't get any better than this. Even with labor to assemble and set it up, and shipping, it's hard to get above $1.50 a gigabyte.
RAID5? BAARF. If you were to use RAID10 instead, you'd still be around $2.1x per GB which is below the original poster's $3/GB max.
I didn't go looking for a Linux-based UPnP media server that can support the Xbox 360 when I posted my previous comment here, though I posited that such software must exist. Today, I accidentally stumbled across the answer: GeeXboX uShare.
While it's intended for GeeXboX, it apparently supports the Xbox 360 (not surprisingly, since the Xbox 360 looks just like a "normal" UPnP media device). I haven't tried it so I can't say how well it works, but it closes the gap. There are now media-serving options for your Xbox 360 from Windows, OSX, and Linux.
A well researched and comprehensive article can stand the author being lazy on his grammar and spelling.
No it can't. The author's lack of spelling and grammar knowledge undermines any other work he may have put into the article. You could have the most well-researched and accurate article ever, but if every "paragraph" is a run-on sentence you're still going to look like an idiot. For crap's sake, at least load the article into a word processor and fix what it complains about (run-on sentences, dammit)! I'll forgive an occassional its/it's or their/there mix-up (if you mix up they're, I will hit you). I can even ignore apostrophes to pluralize abbreviations (apostrophes don't pluralize, dammit). I can't forgive an article that is screwed up to the point of unreadability, even if the research behind it is good.
The tricky part is building such a team. Everyone wants to hire the people with a perfect skillset, hence the insane job requirements that you sometimes see from corporate recruiters. A good vertical skillset in web development makes not only an extremely attractive candidate, but also someone who can easily freelance or do a web startup.
If you're hiring freelancers or contract workers, it's definitely difficult to build such a team. If you're looking to the future and slowly staffing up in a proper manner, then you should have no trouble getting smart people who maybe don't know everything but have an amazing capacity and willingness to learn. Of course, you need to make sure you do spread out the knowledge at hiring time as well. If you hire all SQL programmers, who is going to be your HTML guru who will train the others?
I'd also like to point out that this vertical split works well in many other types of development, not just web dev.
However rather than complete verticality, most of the benefit can achieve from proper overlap. IE, the designer needs to understand HTML/CSS pretty well. The markup person needs to understand presentational logic and the basics of the language being used. The programmer needs to know HTML/CSS and have good database fundamentals. The DBA maybe just needs to understand the business processes.
Depending on where you make the differentiation between "Developer" and "not Developer", your goal should be to get all of your developers to be proficient at all levels. I mention making a distinction because DBAs are often considered Operations (while they may keep your system running, they're not intimately involved in designing and building new features), or your designer is just a Photoshop monkey with a good sense of design and not someone you'd really want coding. For the rest, you play to their strengths but put them in situations just enough beyond their skillset that they will grow and succeed. The other thing here is that by splitting vertically, everybody must grow together. You SQL guru will have to help your HTML guru with his database design and code, just as your HTML guru will have to help your SQL guru with his presentation work. You're forcing teamwork and communication, while spreading out knowledge so that no single person is too valuable (ideally because you're protecting against bad attrition such as a star developer leaving for a different job, but I guess you could use that as a way to slowly outsource everything as well).
You can layer it out a little (one person in charge of database, one in charge of stylesheets/user-interface, everyone else does everything else).
I've found that vertical ownership works out much better than horizontal ownership. Rather than having one database guy, one UI guy, and everybody else writing glue in between, everybody is a database guy and a UI guy and an everything-in-between guy. Developers own features from the database all the way to the presentation. You get a better, more well-rounded team that understands more of the entire project that way, and you increase both morale and responsibility by letting developers own specific features (if a feature is great, you know who to praise. If it sucks, there's no passing blame to "the database guy" or "the UI guy").
You'll still need to have domain experts. Not everybody is going to be a SQL guru or awesome UI designer, so you need team members with those skills who can guide design and implementation, do code reviews, troubleshoot issues, etc. Ideally, these "gurus" are also "regular" team members who own their own feature set. The goal is to spread around the knowledge rather than building little castles around specific areas and throwing around blame. That'll still happen, but it's much harder for Feature A to blame Feature C for Feature A's failure than it is for the database guy to claim his work on Features A and C was perfect and it must be the UI guy who made Feature A suck.
Probably could have cured cancer with that much time/effort, but oh well Halo is more fun.
This is obviously in jest, but it's annoying when people (especially the media) use comparisons like that. Sure, that's 500,000 person years "wasted" on Halo, but spread that over 6.4 million people and you get an average of right around 19.5 person days per person (based on the 50 weeks * 5 days per week calculation), or 156 hours (assuming 8 hours per day). That's certainly reasonable for a multiplayer game like Halo 2. I spent ~90 hours just on single-player Oblivion.
Surely one person could cure cancer given 500,000 years to work on it, but getting 6.4million people to cure cancer in 19.5 work days is not going to happen.
Re:One year of SQL is significant experience?
on
The Art of SQL
·
· Score: 1
so you only look for people who ahve been coding in C# since 2001? I guess you only look a resume of MS emploee's who where on the project thatc reated it...
As I recall, Visual Studio.NET shipped in 2001, which would mean someone could have 5 years of C# knowledge this year (2006). Also, there were public betas of C# and the.NET framework prior to the shipping of VS.NET. Besides all that, I see you got my joke (requiring 5-6 years of experience in a technology that's only been around for 4-5 years).
I assume you mean MSSQL7-MSSQL2005. Which is a horrible database to learn on. I have used almost every version, and Oracle is a lot better. Of course Informix could out perform both of them, but I digress.
Yes, Microsoft SQL Server. I think you should qualify your statement, though. MS SQL Server is a horrible database to learn on if your goal is to ultimately work with Oracle databases. That's a sad fact of the database industry today -- all of the big players are incompatible with each other at some level. None of them implement the full SQL-99 standard (or even the full SQL-92 standard), and all of them implement their own special way of doing things (canonical example: creating an auto-increment column). However, MS SQL Server will at least teach you the basics you'll need on any other system, same as learning on any other good database. If you want a real example of a bad database to learn on, you need look no further than MySQL.
Are we talking parent-child hierarchy tables? If so, Oracle's had statements to take care of that for a long time, since 1998 or so. Perhaps not ANSI standard, but they get the job done.
No, I'm talking about CommonTableExpressions (okay, so I was slightly wrong about implementation of CTEs -- apparently other products have implemented the standard, but DB2 and SQL Server 2005 are the only "Big Boy" engines with them). CTEs aren't so much about implementing a hierarchy as they are about doing recursive actions quickly and efficiently. Walking a parent-child hierarchy is just an example of a recursive problem that's easily solved with a CTE, but CTEs don't dictate how you should store your relationship information.
For what it's worth, it's possible to write recursive algorithms in just about any SQL implementation (convert your recursion to iteration, and it's not so bad), but the win with using CTEs is that it's still a set operation. Doing the loop yourself means you're losing SQL's set-based power. I did a little comparison on a naive parent-child implementation, doing two things: return the path to parent from a given node, and return the subtree of a given node. I implemented each algorithm in SQL 2000's T-SQL without CTEs and in SQL 2005 with CTEs. The CTE implementation was approximately 10 times faster than the by-hand iteration solution.
Slashdot Mirror
I think you left something off at the end. "And if you get it done early, you will be rewarded with even less time for the next project."
For the most part, your ability to give an estimate on a change is a matter of experience. General experience will give you a rough idea of how long it would take to implement some random feature. Specific experience with the system in question will give you a much more refined ability to make an estimate. If you can't make an estimate, or you can only make a rough estimate, be upfront about it. Tell your manager or the customer (if you're the one working directly with the customer) that your estimate is very rough, and try to add as much buffer time as possible. Also, don't get into granular estimates when you can only give a rough SWAG (Some Wild-Ass Guess). If you think it'll take you an hour, say a day. If you think it'll take you a day, say three. If you think it'll take you three days, say a week (experience will tell you how much buffer to add). If you don't have enough experience with the system to make a good estimate, ask your co-workers for help. It's always better to under-promise and over-deliver than the other way around. Besides, while you may end up over-estimating some feature, chances are you also underestimated another one and the extra buffer time you don't need for feature A will be invaluable to finishing feature B.
To help you make better estimates, you should make sure you get a solid set of requirements from your customers. Time should be spent with the customer to determine exactly what it is they want (they may not be able to articulate it clearly), and whether or not there's already a solution they could use if they're only willing to change their process. Avoid telling the customer at that point whether something is "easy" or "hard" (and definitely ignore them when they suggest something will be easy -- they don't know the inner workings of the code, so how will they know if it's hard or easy? Changing a piece of text may look trivial, but may involve a number of external factors such as localization or legal that would turn a 5 minute fix into a two month battle). Take what you've learned, distill it down into a solid set of requirements, and take that back to the customer for sign-off. Once they've signed off, they don't get to change their mind any more for this cycle (however long that may be -- days, weeks, months, or even years, though hopefully not nearly as long as that). Then you get rough estimates from the developers based on their gut feelings and knowledge of the code base, and have them investigate deeper to solidify those estimates. At that point, you have enough to build a schedule, but allow for buffer time! A developer's 8 hour day may not be 8 full hours of coding. It may be 4 hours of coding, two hours of meetings, an hour for lunch, and an hour of "filler" for the cost of task-switching depending on how the coding hours and meeting hours overlap. Based on your experience with past projects, you should have a good idea of how much time per day a dev actually gets to spend on coding and use that to build your schedule. For example, developer estimates are all in 8 hour day increments, but you know from experience that developers average 6 hours per day of productive work. That means a 5 estimated days will actually take 6.7 real days, so use that as your buffering criteria. (BTW, six hours of productive work is actually high. In most cases, it's really closer to 4 or 5.)
Finally, don't forget QA. Just because a developer has confidence that he can implement a specific feature in one hour doesn't mean it won't take QA a week to verify all of the ramifications of that change. You really need to have your QA team working in lock-step with your dev team. Your dev team should write technical specs on the features, and your QA team should estimate impact off of those. The "agile" disciplines that are en vogue lately try to incorporate testing directly into the development process, which is good. However, that means that developers will be in charge of including QA costs on their estimates, which developers are usually bad about doing
New math? Wii math? Maybe you need to go pick up Brain Age for NDS and brush up on your skills :). Also, you don't need a $100 hard drive to save your games. You can use a $40-50 memory card instead. And one would assume you'll need the same for a Wii, so I'm leaving that out of my calculations.
The breakdown (ignoring tax:
- Xbox 360 Core: $300
- Hard drive: $100
- Component cable: $30
- Wireless controller: $60 (minus $20 resale for the wired controller, giving a $40 differential) -- I may be a little off on this one, having not purchased either a wired or wireless controller separate from the console itself.
- Headset: $20
- Grand total to make an Xbox Core into an Xbox Premium: $510 ($490 if you sell the original wired controller from the Core for $20)
- Xbox 360 Premium: $400
- Wii: Rumored price at $250. Your suggested price at $200
For the price of a Core without a hard drive, I could buy 1.25 Wiis. For the price of a Core converted to a Premium, I could buy 2.04 Wiis, but why would I do all of that to a Core when I could buy a Premium instead? For the price of a Premium, I can buy 1.6 Wiis. In other words, I cannot buy 2 Wiis for the price of a Core or the price of a Premium. I could buy 2 Wiis for the price of a Core + everything else, but then I would've just bought a Premium instead. If you use your $200 figure, you still can't get 2 Wiis for the price of one Core, but you could get 2 Wiis for the price of one Premium.More interesting: For the price of a PS3 ($600) + 3 games ($60 * 3 = $180), I could instead buy an Xbox 360 Premium ($400), a Wii ($250), a Microsoft game ($50), a Wii game ($50?), and still have enough left over to buy a GBA game ($30). Or I could buy a third-party 360 game ($60), a Wii game ($50?), and still have enough left over to buy Halo 2 ($20).
Both Nintendo and Sony had online options in the Xbox/PS2/GC generation, but Xbox Live was the clear winner. Sony's now planning on copying Xbox Live for the PS3, and Nintendo's retro game market looks like it's strongly influenced by Xbox Live's marketplace and Arcade. Nintendo and Sony may get their acts together, but Microsoft has a huge lead (in knowledge, implementation, and mindshare) with Live that will be tough to beat.
I'd rather have a 720p TV than a 1080i (interlacing == flickering == hurts my eyes, and 720p has more usable resolution, as 1080i's vertical resolution in movement is really only 540). A 1080p system is a waste of money right now (check back in ~2 years). And that's why I replaced my old 1080i TV with a new 720p TV last November.
Keep in mind that "graphics quality" involves more than just higher resolution textures. It means more detailed models, more objects on screen at a time, more realistic rendering effects, etc. All of that will be noticeable on a standard-definition TV. Of course, it does still depend on developers using the full power of the system. If a developer just applies higher resolution textures and anti-aliasing to PS2-grade graphics, that's going to suck on any TV (see Gun, several of the sports titles from Xbox 360 launch).
It always boils down to number of available games. I wouldn't count out Xbox Live Arcade just yet, either. And with Sony losing GTA's launch exclusivity, there's one less reason to buy a PS3.
While I'll probably end up buying all three (I have a 360 now, I'm planning on getting a Wii at launch, and I'll pick up a PS3 in 3-4 years when it's affordable), my current plan is to go Wii60.
Speaking of Windows, different multi-core processor architectures, Virtual PC, and .NET, have you looked at Xbox 360 lately?
As much as I love my Xbox 360, I have no illusions of it taking over all (any!) of my general-purpose computing (nor do I expect or want the PS3 to do so, Kutaragi!). However, when you look at the bullet points it's pretty easy to come to the conclusion that Xbox 360 may just be an incubation project for future hardware architectures and operating systems.
I think the key point to keep in mind here is not that Microsoft is looking for a successor to Windows, but that these statements came from "a program manager for external research programs in the Microsoft Research group". This is what Mirosoft Research does. They come up with blue-sky ideas like replacing Windows entirely, and then the product groups integrate those ideas into real, shippable products. As an example, the "Drivatar" AI used by Forza Motorsport came directly out of MSR. The researchers had grand plans for the technology (get real motorsport "legends" to generate drivatars based on their driving style, learn from the player as he's playing, etc), while the implementation in Forza was more practical (the main AI was based on pre-release training and didn't learn from watching the player, there were no "professional" drivatars, the player had to actively train his drivatar in specific sessions rather than having it learn while he plays, etc). That's not a bad thing, and it's still a damn sight better than most other racing game AI out there (Gran Turismo, I'm looking at you. Damn retarded bumper car AI ...). Researchers are good at coming up with crazy ideas and sample implementations that don't take into account the rest of the system (back to Forza, there's only so much processing available in an Xbox to handle all of the physics and AI, which means that real-time drivatar training wouldn't be feasible). If you know what to look for, you can see many Microsoft Research contributions in shipping products (speech, grammar checking, natural language processing, etc in Office; anti-phishing in the MSN/Windows Live Toolbar and IE7; pretty much the entire backend for MSN/Windows Live Search; and so on), but it's only bits and pieces. Go poke around, look at the many areas of research going on at MSR. Take a look at their sample code. And then remember that when you see a similar but less-grandiose feature 5-10 years from now in a real, shipping product.
Note: I'm neither a Microsoft researcher nor a Forza developer, so all of the information above is what anyone can deduce from the sources I cited.
Microsoft has already done this to a fair extent with Terminal Server. The main thing to keep in mind is that the main bits in kernel space really are drivers, not the UI framework (and even that's changing with Vista). Terminal Server is very much Microsoft's X. Do you remember the "Fast User Switching" feature in Windows XP? Yeah, that's Terminal Server, and what it really means is that every time you use the Windows UI (in XP and 2K3) you're actually interfacing through a local Terminal Server session (just like X!). Of course, TS will have its little differences when running over a network, like not supporting video overlays or 3D acceleration, but in most case
Relocate! If you can't find good work doing what you want (getting paid near minimum wage isn't "good work"), and you're not willing to do something else instead, then it's time to move. If you are such a smart and talented "geek", you should have no problem finding a job elsewhere.
You fail the apostrophe test.
The only flaw in your strategy is that it requires the buyer to be willing to also become a seller. Many times, this is not the case. For example, I've only purchased a few items via ebay over the years. I've sniped most of those auctions because they were things that I would like to have but weren't so critical that I would care if I lost, while at the same time I wasn't so invested that I wanted to bid on tens of different auctions. If I win, I get what I wanted. If I lose, I don't. Most importantly, I don't run the risk of winning multiple auctions, having to pay for that merchandise, and then try to flip it. Since I rarely use ebay, it should be obvious that I have low reputation (what I do have is good, but there's not much there) which can hurt sellers. I don't want to spend my time listing the auction and hoping I can sell the item for enough over what I paid that I can at least break even.
For casual users like myself, sniping is the only way to go. Your method requires too much investment, and "normal" bidding will result in bidding wars that could end up costing way more than the item is worth. Sniping from a position where you don't care if you lose Just Works (tm).
I've not used ReiserFS (my linux box runs on XFS, for no real reason other than it was the cool thing to do six years ago), but on the face of things I don't think your claim is correct. ReiserFS (or as you linked, Reiser4, since ReiserFS/Reiser3 has ceased development but for critical issues) is a metadata-only journalling filesystem, still based around a directory structure. In other words, it's just like NTFS, though each FS has features the other doesn't (ReiserFS has better fragmentation management, NTFS has integrated encryption, etc). WinFS, on the other hand, is a relational-based filesystem that intended to do away with directory structures entirely (you could still have folders/directories, but they'd be "virtual" -- storage of files was not tied to any specific folder or directory). At the same time, WinFS isn't a "true" filesystem, but another enhancement on top of NTFS.
FS comparison on Wikipedia.
One may find it difficult to fit an AMD CPU on an Intel motherboard. Pesky competition.
As the grand-parent said, he had to exchange a motherboard. That means he wasn't intentionally upgrading, thus expecting to continue to use the rest of his hardware (memory, disk, CPU). Were this a system upgrade rather than a replacement of a faulty part then it may be useful to suggest he look at an Intel-based solution. As it is, he obviously already had an AMD CPU and so he needed another motherboard that would work with said CPU.
Which is wrong. Or, well, not exactly right. Bigman answered his own (rhetorical?) question correctly already:
In other words, Barbie Horse Adventure either used the same engine as some other game, or was so technically simple that it just works without any extra hacking. Why they bother to list it on the BC list is beyond me, though. Maybe the 6 year old girl demographic is really important?Well, the 360 is designed to eventually break-even or even make money, which the Xbox was not. So, Microsoft will not be as pressed to get the Xbox 3/720/Next/whatever out in another 4 years. And if all goes well (poorly, that is) with the PS3, Microsoft will be in a much more comfortable position and not have to fight for first-mover status like they did with the 360.
That said, even during the Xbox's four years, you could visibly see developers making advancements in technology. A good example is Halo vs. Halo 2. Not only did things get shinier/bumpier (adding more detail through bump mapping techniques rather than geometry), they also were able to render in widescreen while the original didn't. If you compare Project: Gotham Racing to PGR 2, you'll see similar changes -- better trackside textures and models, better textures all around, better car models and environment maps, etc. And then compare PGR2 to Forza, and you'll see even more differences (though some are under the covers, such as the 4-wheel independent suspension physics simulation used in Forza, compared to the standard of Pacejka's Magic Formula). It's certainly not as much of an improvement as we saw through the life of the Playstation (compare Final Fantasy VII to Final Fantasy IX), but it's still there and once would expect similar advances on the 360 as developers get used to the technology.
I know this is Slashdot, so you obviously didn't read the article. Did you even read the summary, though? This bit was quoted in part right there in the summary:
In other words, Microsoft and third-parties already have ways to procedurally generate textures and models so that an artist doesn't have to toil over "dozens and dozens of slightly different tree models", for example. Adoption of such techniques will only increase as games get ever more complex.That's all well and good, but it's a limited approach. The obvious issue is that it works best for PCs, where people have the full power of a PC (and thus developer- and community-provided tools) to build mod content. That's not going to work nearly so well on a console. More importantly, IMHO, is that the developer still has to provide some content to get you going, or most people won't stick around long enough to create their own. Finally, this doesn't necessarily work for all genres. It'll work with Spore because that's a sandbox game. It wouldn't work so well with Half-Life or Halo, because the single-player portions of those are too important (you can get community involvement for multiplayer, but the developers are still going to have to produce huge amounts of high-quality art for the single-player experience).
I disagree. This is part of the future of gaming, but I really hope it's not the whole future. That's like saying blogs are the future of book publishing, or YouTube is the future of movies. It's great to give your users/fans/players a way to contribute back, but unless every game is just another Sims sandbox (boring!), we'll still need the "masters" (as in, professionals who are dedicated to their art, with the resources to produce outstanding work) to provide us with compelling stories, graphics, AI and behaviors, etc. Some of that may be procedurally generated, but at the root of that should always be a professional artist.
Because integrated devices generally suck. Go back to the PS2 in 2000. Why would you buy a $500 stand-alone DVD player when you can buy a PS2 for $300 that does the same plus more? Because the PS2 was a horrible DVD player. Do you really expect the PS3 to be a great Blu-Ray player?
Of course, that's assuming you buy into Blu-Ray at all, or that you must be an early adopter of the format. Personally, I'm going to wait it out. I may eventually buy a PS3, but it won't be for Blu-Ray. I may eventually buy a HD-DVD or Blu-Ray player, but not until the format war shakes itself out, prices drop to a sane level ($500 or less, preferably $300 or less), and the available library of movies grows. Until then, my $100 upconverting DVD player looks awesome at 720p (via HDMI), as does my Xbox 360 at 720p (component). My TV doesn't do 1080p, because a) 1080p is still too expensive, and b) nothing uses it yet (TV upscale/de-interlace generally sucks, so if I have to do conversion I'd rather it be done at the player level, like an upconverting DVD player).
All of the Splinter Cell games have been that way. Also, don't forget the Hitman games. While they do allow you the option of running and gunning through the game (nearly impossible in Splinter Cell, impossible in Thief), you can only get Silent Assassin rankings by leaving no trace. That means not killing anybody but your assigned target, nor doing anything suspicious that might alert others, leaving your changes of clothing or guns lieing around, etc. In some cases, this may even extend to as far as closing doors you opened, because finding an open door may alert guards or civilians to your presence
It all boils down to what's "easy", I think. It's not easy to make a fun, compelling game where your entire goal is to accomplish your objectives without ever being seen or heard. It requires exceptional control mechanics, AI, level design, and more. A number of games have tried, and most have failed. It's much easier to do a straight-forward run 'n gun like Doom (though even that is difficult to do well -- Serious Sam is really the best example of fun mindless action).
Trouble is, you're going to have to read through a lot of painful crap before you find something that justifies this position. For me, if grammar and spelling is so horrible that I can barely make it through the first paragraph (worse, if the first paragraph is of normal length, but a single sentence), I'm going to skip the article. Maybe by doing so I'll miss the cure for cancer, but I'll take that chance.
I'm the last guy that should say anything, but I can't help myself. That should be "can't write properly", being an adverb that modifies the verb "write". :)
I have a feeling that language skills have always sucked. We're just seeing it more today because it's getting ever easier for non-professionals to write something that has a chance of being read widely. I'm sure if you looked at personal letters from your grandparents' generation, or even your parents', you'd find just as horrible spelling and grammar. I've read old letters between my aunts and my mom from a couple decades ago, and the spelling and grammar is just as bad as it is today. IM/Text-speak crap like "u", "r", "2", etc, hadn't entered the vernacular yet, but common failings like it's/its, their/there/they're, lose/loose, chose/choose, and more are all represented.
Nothing a little ingenuity can't fix. Go buy yourself a roll of parchment paper (silicone-impregnated paper used for high-heat cooking where wax paper would melt or aluminum foil would react with acidic foods, available at grocery stores everywhere). Using a CD as a template (the clear plastic top "disc" of most spindles would be perfect), trace out a number of CD-sized circles, cut them out (a hobby knife or other sharp knife would be best, as it'll be difficult to cut out the centers with scissors), and sandwich them in between each disc. No more sticking!
RAID5? BAARF. If you were to use RAID10 instead, you'd still be around $2.1x per GB which is below the original poster's $3/GB max.
I didn't go looking for a Linux-based UPnP media server that can support the Xbox 360 when I posted my previous comment here, though I posited that such software must exist. Today, I accidentally stumbled across the answer: GeeXboX uShare.
While it's intended for GeeXboX, it apparently supports the Xbox 360 (not surprisingly, since the Xbox 360 looks just like a "normal" UPnP media device). I haven't tried it so I can't say how well it works, but it closes the gap. There are now media-serving options for your Xbox 360 from Windows, OSX, and Linux.
No it can't. The author's lack of spelling and grammar knowledge undermines any other work he may have put into the article. You could have the most well-researched and accurate article ever, but if every "paragraph" is a run-on sentence you're still going to look like an idiot. For crap's sake, at least load the article into a word processor and fix what it complains about (run-on sentences, dammit)! I'll forgive an occassional its/it's or their/there mix-up (if you mix up they're, I will hit you). I can even ignore apostrophes to pluralize abbreviations (apostrophes don't pluralize, dammit). I can't forgive an article that is screwed up to the point of unreadability, even if the research behind it is good.
If you're hiring freelancers or contract workers, it's definitely difficult to build such a team. If you're looking to the future and slowly staffing up in a proper manner, then you should have no trouble getting smart people who maybe don't know everything but have an amazing capacity and willingness to learn. Of course, you need to make sure you do spread out the knowledge at hiring time as well. If you hire all SQL programmers, who is going to be your HTML guru who will train the others?
I'd also like to point out that this vertical split works well in many other types of development, not just web dev.
Depending on where you make the differentiation between "Developer" and "not Developer", your goal should be to get all of your developers to be proficient at all levels. I mention making a distinction because DBAs are often considered Operations (while they may keep your system running, they're not intimately involved in designing and building new features), or your designer is just a Photoshop monkey with a good sense of design and not someone you'd really want coding. For the rest, you play to their strengths but put them in situations just enough beyond their skillset that they will grow and succeed. The other thing here is that by splitting vertically, everybody must grow together. You SQL guru will have to help your HTML guru with his database design and code, just as your HTML guru will have to help your SQL guru with his presentation work. You're forcing teamwork and communication, while spreading out knowledge so that no single person is too valuable (ideally because you're protecting against bad attrition such as a star developer leaving for a different job, but I guess you could use that as a way to slowly outsource everything as well).
I've found that vertical ownership works out much better than horizontal ownership. Rather than having one database guy, one UI guy, and everybody else writing glue in between, everybody is a database guy and a UI guy and an everything-in-between guy. Developers own features from the database all the way to the presentation. You get a better, more well-rounded team that understands more of the entire project that way, and you increase both morale and responsibility by letting developers own specific features (if a feature is great, you know who to praise. If it sucks, there's no passing blame to "the database guy" or "the UI guy").
You'll still need to have domain experts. Not everybody is going to be a SQL guru or awesome UI designer, so you need team members with those skills who can guide design and implementation, do code reviews, troubleshoot issues, etc. Ideally, these "gurus" are also "regular" team members who own their own feature set. The goal is to spread around the knowledge rather than building little castles around specific areas and throwing around blame. That'll still happen, but it's much harder for Feature A to blame Feature C for Feature A's failure than it is for the database guy to claim his work on Features A and C was perfect and it must be the UI guy who made Feature A suck.
This is obviously in jest, but it's annoying when people (especially the media) use comparisons like that. Sure, that's 500,000 person years "wasted" on Halo, but spread that over 6.4 million people and you get an average of right around 19.5 person days per person (based on the 50 weeks * 5 days per week calculation), or 156 hours (assuming 8 hours per day). That's certainly reasonable for a multiplayer game like Halo 2. I spent ~90 hours just on single-player Oblivion.
Surely one person could cure cancer given 500,000 years to work on it, but getting 6.4million people to cure cancer in 19.5 work days is not going to happen.
As I recall, Visual Studio.NET shipped in 2001, which would mean someone could have 5 years of C# knowledge this year (2006). Also, there were public betas of C# and the .NET framework prior to the shipping of VS.NET. Besides all that, I see you got my joke (requiring 5-6 years of experience in a technology that's only been around for 4-5 years).
Yes, Microsoft SQL Server. I think you should qualify your statement, though. MS SQL Server is a horrible database to learn on if your goal is to ultimately work with Oracle databases. That's a sad fact of the database industry today -- all of the big players are incompatible with each other at some level. None of them implement the full SQL-99 standard (or even the full SQL-92 standard), and all of them implement their own special way of doing things (canonical example: creating an auto-increment column). However, MS SQL Server will at least teach you the basics you'll need on any other system, same as learning on any other good database. If you want a real example of a bad database to learn on, you need look no further than MySQL.
No, I'm talking about Common Table Expressions (okay, so I was slightly wrong about implementation of CTEs -- apparently other products have implemented the standard, but DB2 and SQL Server 2005 are the only "Big Boy" engines with them). CTEs aren't so much about implementing a hierarchy as they are about doing recursive actions quickly and efficiently. Walking a parent-child hierarchy is just an example of a recursive problem that's easily solved with a CTE, but CTEs don't dictate how you should store your relationship information.
For what it's worth, it's possible to write recursive algorithms in just about any SQL implementation (convert your recursion to iteration, and it's not so bad), but the win with using CTEs is that it's still a set operation. Doing the loop yourself means you're losing SQL's set-based power. I did a little comparison on a naive parent-child implementation, doing two things: return the path to parent from a given node, and return the subtree of a given node. I implemented each algorithm in SQL 2000's T-SQL without CTEs and in SQL 2005 with CTEs. The CTE implementation was approximately 10 times faster than the by-hand iteration solution.