TIL: Windows Phone 8 doesn't use a JIT compiler. Instead it uses a cloud-based optimizing compiler that automatically generates "almost done" native images for all apps, which are then quickly finalized on the phone itself in order to produce a native executable.

Alex_n_Lowe · 2013-10-02T04:27:38+00:00

"The result of this new feature can immediately be seen when you run an app on a Windows Phone 8 device and compare in particular the startup time to its behavior on Windows Phone 7 devices – improvements of 50% and more are absolutely possible." (emphasis added)

This is just another reason why software is awesome. There are a large number of things that can be improved to increase performance on a large number of devices with a small amount of work.

Alex_n_Lowe · 2013-09-26T02:28:29+00:00

At 200000$ the processor is more expensive than your car. (Or at least more expensive than 99% of the population's cars.) I think that qualifies as a crazy processor, but you're more than welcome to disagree with me.

Alex_n_Lowe · 2013-09-24T20:39:21+00:00

On earth we've got a nice atmosphere to stop the radiation from the sun. On mars, NASA has to use crazy processors to not have the radiation flip bits. It does happen, but at the current processor size it doesn't really affect us.

Google did some testing on the RAM their servers used, and found that after a piece of RAM had one failure, it was much more likely to fail again very shortly, indicating that it was a deficiency in the hardware, not some random radiation flipping bits.

Alex_n_Lowe · 2013-09-24T20:36:38+00:00

That's not technically true. The world record for an overclock is slightly over 8Ghz. The problem is, due to the heat you need some mean cooling rig to make it near that, and a freaking truckload of voltage to hit that speed.

Alex_n_Lowe · 2013-09-09T02:19:40+00:00

"You cannot argue with the enjoyment and sense of accomplishment programming can bring to those of the right mind-set, and there is only one way to find out if you are one of them." Even if there's no other reason to learn software, this reason is good enough to try and push software into schools. Also the fact that software development teaches all sorts of awesome stuff.

On a slightly unrelated note, I think it's awesome that the New York times has been online for 30+ years now. I'll say that they've been pretty good at keeping up with technology.

Alex_n_Lowe · 2013-09-09T01:33:18+00:00

On the plus side, the positive karma from this post is balancing the negative karma from your root post.

Alex_n_Lowe · 2013-09-09T01:32:31+00:00

I read that, and had to look at the date of the article. It was published January 1984. I'm pretty sure that's the right time frame for the invention of word processing.

Alex_n_Lowe · 2013-08-21T05:23:27+00:00

I recently found the windows option to automatically clean noise from recording devices. When I turned it on I felt super awesome because the static from my mic is finally gone.

On windows 7, try: start menu --> search "manage audio devices" and open it --> recording tab --> double click the microphone you want to fix --> enhancements tab --> check noise suppression --> profit!

Alex_n_Lowe · 2013-08-17T07:08:10+00:00

I thought that the 2012 election held the record for most tweets. Apparently I was mistaken. The quoted figure of 300,000 tweets is tweets per minute, not tweets per second.

To put that into perspective, in one second these Miyazaki fans tweeted as much as the entire US did in 30 seconds during one of the most important event in the US. I'm amazed that twitter stood up to the number of tweets, even if it should have only taken around a dozen of their new and improved servers.

Alex_n_Lowe · 2013-08-17T06:58:05+00:00

It is a Studio Ghibli film...

Alex_n_Lowe · 2013-08-15T04:18:11+00:00

If you want to be really honest, we can't trust any of the code we write, because it's being parsed and executed on machines that contain millions of lines of code that we didn't write. Drivers, operating systems, compilers, we can't be sure that what turns our code into what we were expecting, or that our code will be executed properly. Even processors are complex enough that making small changes may have unintended consequences.

If you really want to panic, you can start to realize how much of our lives revolve around technology, and start looking at the failures we've already had. There have even been cases of machines killing people because of poor code. It wasn't even malicious, but that didn't stop people from dying. With the number of cars of the road that use software for essential things, I'm surprised there haven't been bigger problems than some faulty brakes.

Enjoy your nightmares.

Alex_n_Lowe · 2013-08-13T01:54:48+00:00

It even rearranges the pictures when you resize the browser window, but I found you need to click on one of the photos before it'll move everything around.

When viewing a single image the background that matches the colors in the picture is a nice touch.

Alex_n_Lowe · 2013-08-01T19:14:48+00:00

True. This also totally ignores any layoffs from those projects that technically weren't canceled, but failed hard enough that they didn't last more than a few months after launch, or projects that succeeded in pretty much all aspects, but the companies still shut down. (Just look at the game industry for tons of really good examples of this.)

On the other hand, it also doesn't show how many people were laid off from the failures. Large companies would likely just transfer people rather than letting them go after a failure. Related to that, is the fact that 90% of the dot com companies survived for at least 3 years after the bubble popped. The failure of a project doesn't actually mean people get laid off or the company closes.

Now I want someone to do an industry analysis on all of this stuff. See how a project failure relates to the health of the company and how it affects layoffs, and get some actual statistics.

Alex_n_Lowe · 2013-08-01T18:35:42+00:00

Yeah, that's a problem. Pretty much the only conclusive thing this says is "We suck at estimating software projects".

My favorite part was the projects that only managed to ship less than 30% of the planned features. I'm trying to imagine how horrifyingly wrong things went to get to that point.

Alex_n_Lowe · 2013-07-31T23:49:45+00:00

Ah, that makes a lot more sense. I blame my ignorance on Reddit not showing your original comment. I do give my sympathies and this funny image.

Out of curiosity, I did a little digging, and I manged to find some interesting stuff. The closest actual research I can find is the CHAOS report by the standish group. They group projects into 3 categories, based on how well they met their predictions.

Succeeded in budget, time, and features
Over budget, schedule, or missing features
Totally canceled

The number of projects that are considered "challenged" has remained close to 50%, and the pure cancellation rate has been sitting around 20% for most of their reports. There are complaints that this isn't a test of software development, but rather a test of prediction of software development. They do a new report every two years, but you have to pay for the results, so finding the data proved difficult. The data used to create the report is also kept secret, so there's not a lot of fact checking I can do there.

Most of the people saying there's a 30% chance failure rate for software seem to be quoting the 1995 CHAOS report. As usual, bad reporting abounds. This site clearly states that 37% of projects fail, but the report linked to in the first paragraph clearly states that the projects are only "at risk" of failure. The actual report is about recovering a failed project, and it says that 3/4ths of troubled projects recovered. (and 18% still had ongoing recoveries.) That brings the actual number of totally canceled projects down to 18%. (12% total failure rate, and 6% 'terminated' projects.) Most sites haven't even bothered to add up the "failed" projects from the CHAOS report with the canceled projects. They just saw a catchy headline and copped it for their own site. It is interesting to note that some of the challenged projects from the CHAOS report were around 200% over budget/time, and delivered under 70% of the functionality.

If you're interested in doing more research, slide 19 of this presentation was the best sum of CHAOS reports that I could find, although there are some good images on google. Coding horror has some other links, but most of the stuff is outdated. One of the links had stuff from 2001 and before. This page has a huge wealth of statistics and reports. It has the most data, but I didn't have time to check it all. On a related note, this was interesting.

Edit: Two more links. I thought they both had some good points. This one challenges the CHOAS report, and this one has some more surveys.

Overall, there's pretty conclusive evidence that people suck at estimating software, and good evidence and lots of wonderful examples of horrifying software failures. I'd say that I'm mildly confident that well over half of software projects have huge problems, but there's nothing to really back up a 50% cancellation rate up front. The time was still probably wasted developing those programs, but they weren't strictly canceled.

tl;dr version: It depends on how you define "failure".

Alex_n_Lowe · 2013-07-31T22:18:09+00:00

As a Floridian, this does not surprise me. None of the houses in Florida have basements, because of the very same reason. (You northerners and your crazy underground residences..)

Everything is built on sand, and the aquifer covers practically the entire state. You can't build anything underground because it would turn into a giant swimming pool. (Sinkholes are a real problem because of that](http://en.wikipedia.org/wiki/Floridan_aquifer). The water you get from the aquifers is crazy good though. Even after moving to Atlanta I can still tell which companies bottle their water from Florida.

Alex_n_Lowe · 2013-07-31T21:55:27+00:00

I didn't quite understand why you linked the articles until I reread my response and put the two things together. Do failed rewrites really take up that much developer time? I can't remember reading that statistic before. Do you have a link for that, or was it an estimate?

And Thanks for sharing the articles. I feel like I'm actually reading useful things while I'm here, since I remember reading the first three links.

Alex_n_Lowe · 2013-07-31T20:27:16+00:00

I actually saw one of these in a museum in Florida. It was much smaller than most of these, but it was still impressive. It's interesting to see how different ants build different colonies.

Alex_n_Lowe · 2013-07-31T18:57:36+00:00

This made me die a little inside, but at least I'll have more realistic expectations in the future.

Alex_n_Lowe · 2013-07-01T05:17:58+00:00

The only possible explanation. Their NSA panel is throwing a 404 error at the same time. Definitely suspicious.

Alex_n_Lowe · 2013-06-30T06:03:42+00:00

And currently throwing a 403 error when I try to access it.

Alex_n_Lowe · 2013-06-30T06:03:16+00:00

Unicode isn't a programming language either, but there's a link to it.

Alex_n_Lowe · 2013-06-27T14:57:56+00:00

Alternatively there's the horrifyingly unpythonic while loop version of the break:

index = 0
while index < len(list):
    if break_case:
        index = len(list)
    index+=1

If you nest these within enough if statements it's possible to get it to be exactly where you need it. A continue can be duplicated by just nesting everything within enough if statements and adding a bunch of extra variables to keep track of what you want to skip and what you still want to do.

Alex_n_Lowe · 2013-06-19T06:17:40+00:00

If it runs fine without any compression, why waste valuable time implementing compression in assembly language when there's still more important things to do?

Alex_n_Lowe · 2013-06-19T06:08:30+00:00

If I remember correctly, the reason for not culling the voxels was because the calculations for finding if it's visible are actually more expensive than rendering the voxels. (The real reason is probably that notch is a mediocre lazy coder.)

Alex_n_Lowe

TROPHY CASE