UPDATE: The smiley face next to my little Rails joke wasn’t strong enough, added a bit, plus a link.

We’re here to talk about some boring stuff. Get-more-fiber-in-your-diet kind of stuff. It’s titled “Development Techniques” on the schedule, but this talk might be better to call it “Best Practices in Software Engineering”, or “Good Habits When Making Software”, or “Ass-saving Shit That Some Other Smart People Figured Out, Because Your Problems Aren’t New.”

My favorite metaphor for explaining programming to non-coders is that it’s like carpentry. You can put together a chest of drawers with nails and glue, and it’ll fall apart in a year, or you can build something lasting and use dovetail joints. We’re not plumbers providing a utility, but neither are we artists. It’s nice if our work is beautiful, but it also must be durable. We’re craftsmen. We make things that people use.

The point of all this is that craftsmanship matters. So, I’m here to ask you to change your ways, to consider adopting some processes, not because they’re fun, but because they’ll save your ass, and help you do better work. And once you’re in the habit, of writing tests and deployment scripts, of tracking your defects and versioning your code, you’ll wonder how you ever went without.

So, we’re trying something new today. I’m gonna run through these concepts fairly quickly, and in-between, Jacob will reflect on his work adopting many of these practices. It shouldn’t take very long, and at the end we’ll take questions.

Version Control

Version control software is both a safety net and a collaboration tool. It’s a place, usually away from your machine, where you store your code. And when you write new code, it hangs on to your previous versions. Even on a one-person project, version control is essential. When your hard drive crashes, you don’t lose your work. And, when you’re working with others on a common codebase, it acts as a central repository to help coordinate everyone’s changes.

We use Git. Other folks like Mercurial. Subversion would also be a fine choice, though it’s no longer the cool kids’ favorite.

Task Tracking

It may sound bossy, but task tracking is not about micromanagement, or at least it doesn’t have to be. In my experience, on any project, you’ll only really know how deep in the weeds you are if you can see all the tasks, listed out. Also, I find that forgetting to do something is extremely embarrassing. So, you can track tasks in a text file or in a spreadsheet on your desktop, but I’ve found thats teams work better if the TODO list is out in the open. So, go low-tech and use 3×5 cards pinned to the wall — or go high-tech and use one of many software packages designed for the purpose.

We use Unfuddle. Trac is also a fine choice. If you’re using GitHub for hosted Git version control, it comes with issue tracking, but I haven’t heard many people express their love for it. That said, it might be worth a shot.

Defect Tracking

When you find a defect, log it. Take a screenshot, and type up sufficient details to reproduce the problem. This may seem heavy-handed, but defects are your unplanned tasks, they must always be addressed — either by fixing them, or explicitly choosing to let them slide. Known defects are totally okay. But unknown defects, on the other hand, are the devil. So, always, always, please record your defects, even if you’re going to fix them immediately. One of these days, you *will* get distracted half-way through a fix. And you *will* forget. Unlike tasks, I’d say always take the high-tech route with defects. They’re best tracked with software.

We use the same system to track our tasks and defects, Unfuddle. Usually you do it that way. Another catchall option that might work for you is FogBugz.

Staging Environment

Similar to defect tracking, your staging environment is there to reduce uncertainty. It’s an environment — servers, your databases and applications, everything — that you run in parallel to production. It should be identical to your production system. (If you’re using Amazon EC2, this is pretty much as simple as copying your production instance!) Your goal is this: knowing that, if your application works in staging, it will work in production. You can execute load tests and performance tests against your staging environment, as well as test your deployment scripts, and, as a bonus, it can host your work for demos, etc.

We use Amazon EC2 for our hosting, and keep carbon-copy instances running in staging and production at all times. We’ve written about how to set up your own EC2 environment on our team blog.

Load Testing

The Tribune news apps team learned an important lesson in February, when Illinois voters went to vote in the primaries, and our Election Center app was put to the test. We had thought our production setup was great. The harder we abused it, the more load we threw in our tests, it just kept performing. “Great!”, we thought, “This system is gonna work awesome.” Well, you can probably guess where I’m going with this.

We crashed and burned on election day. The Election Center was useless. (For the server nerds in the audience — our top was pegged well over 100.) Luckily, a few Google searches gave us a way to route around the bottleneck (using the awesome pgpool), and we were back up and running after only a half hour or so. The lesson we learned was this: A good test must fail. You need to know your breaking point. Make the servers effing cry. Because they *will* cry. And if you don’t know your limits, you’re asking for trouble. We got very lucky. There was a readily-googleable, turnkey fix for our problem. We might not be so lucky next time.

We use ab to make our servers cry.

Push-button Deployment

When everything is running smoothly, a multi-step deployment process (gather the code, FTP it all to the server, restart apache, etc.) doesn’t seem like so much of a hassle. But when the shit hits the fan, your editor is breathing down your neck, and you’ve gotta fix that bug, fast — let’s say, on an important election day — you’ll screw up. You’ll forget something, and your minor bug will become a nightmare. Everything will break, and you’ll be even more freaked out.

Push-button deployment won’t fix your bugs, but it will help you keep your cool. It will also saves you from the tedium of redeployment, and act as a guide when you need to redeploy your project months or years down the line. If you’re running an identical staging environment, you’re even better off, because you can develop your deployment script for staging, use it a few dozen times, and then when it’s time to roll to production, you know it’ll work.

You can write deployment scripts on your own but there are lots of great tools out there, built to make deployment dead-easy. We use Fabric, and have written about our scripts in great detail. If you’re into Ruby, I’m pretty sure that Capistrano is the current state of the art.

Web Frameworks and Agility

Making websites used to be slow work. Web frameworks make you fast. If you’re fast, you can, obviously, turn around projects in a more timely fashion. But, the maybe less obvious advantage of high-speed development tools is that they enable you to fail fast. And what I mean by that is, it used to be that you’d have to write code for a month before you had anything you could show off. Using frameworks, you can create something interesting very quickly, in days or hours, and the faster you create, the faster you can be critiqued. We never go more than a day or two between show-and-tell sessions with reporters, and when we’re working on a long-running project, we hold reviews with our stakeholders every Friday afternoon. Frameworks enable us to learn from our mistakes and correct course very quickly. They enable us to be agile.

We use Django, a web framework with deep roots in the news industry. There are people here who will tell you to instead use Ruby on Rails. They are not to be trusted. I kiiid. Check out Aron Pilhofer’s post, How Not to Choose a Web Framework.

Testing

Automated tests kick ass. It’s not immediately obvious, but ‘testing’ is about more than merely ensuring correctness. Tests can help you write code faster, and they can save you six months down the road when you’ve half-forgotten about your project. But before they can save you, you’ve gotta write ‘em. The tests I most commonly write are called ‘unit tests’. A unit test is a bit of code that checks if another bit of code you’ve written works properly. For example, let’s say you’re writing a web application that calculates people’s income tax obligations. There are a lot of special cases that vary on how much money you make, if you’re paying a mortgage, etc. To test your calculations, you could visit the web page you wrote, over and over again, typing in each special case you can think of. If you’re especially thorough, you might even keep a spreadsheet to check off correct numbers. This would be thorough, but insane. Instead, you should write unit tests — code that exercises each special case automatically, by testing your calculations directly. First, you won’t waste countless hours reloading a web page, and second when, six months later, they update the laws and you’ve gotta fix your code, you can test all the permutations again at a keystroke.

Most web frameworks include a rig for easily testing your work.

Further Reading

I’ll keep the book list short. Pick these two up. Know them. Love them.

• On software craftsmanship: The Pragmatic Programmer
• On running projects, and much else: Rework

Tools we love to use

• Quick-install Python/PostGIS geo stack on Snow Leopard
• Deploying ProPublica’s awesome table-setter tables to S3 using Fabric
• Quickly visualize and map a data set using Google Fusion Tables

Development techniques and best practices we’ve discovered

• Best practices in web development with Python and Django
• Advanced django project layout
• Refactoring fabfile.py for fast, robust Django deployment
• Fun with widgets and caching

Sharing our infrastructure

• Hello, Newsroom: a simple GeoDjango application
• Our GeoDjango Amazon EC2 image for news apps
• Nerd post roundup and preview (plus: our server architecture!)

For links to our recent projects, and to keep up on our work, visit apps.chicagotribune.com!

Join our team!

Requirements:

• A passion for the news
• An understanding of the inner workings of the web
• Attention to detail and hatred for inaccuracy
• A genuine and friendly disposition

Position one: User experience designer / information architect

Our team is in need of someone who will lead the design conversation. Someone who will interview stakeholders, develop personas, intuit features, arrange information, draw mockups, and everything else necessary to design a web site. You will work fast and agile, in tight iterations, and in close contact with our stakeholders — the editors and reporters of the Chicago Tribune.

You should also be ready to close the loop and put our work in front of users, take their feedback, and redesign it all — cuz that’s what you gotta do when you’re agile.

You must care deeply about usability and grok the web.

Extra points if you love to sketch, didn’t have to google ‘grok’, and don’t need an education on agile development practices.

Position two: Web designer / developer

We are also in need of a creative web designer. Someone who cuts tight, valid and semantic HTML/CSS and makes it look *hot*. Graphic design skills are a must, but we also require the ability to implement those designs. We need more than a photoshop jock. You will work fast and agile, in tight iterations, and in close contact with our stakeholders — the editors and reporters of the Chicago Tribune.

(If you’re a print designer, you’re probably not who we’re looking for, but we’ll do our best to not be prejudiced. Show us you’ve got serious web chops, and we’ll talk.)

Extra points if you have worked with Django (we’ll welcome Rails skillz too, they translate) and have built many beautiful websites.

Even more points (for both positions) if you know a thing or two about:

• Data science (statistics, exploratory data analysis, R)
• Information design (beautiful charts, graphs and other Tufte-geekery)
• Building and gardening social media or crowdsourcing applications

Some days we’ll huddle and sketch with reporters, imagining ways to present information and tell their story on the web — and we might turn that story around in a day, a week or a month. Other days, we’ll develop news products that’ll take months to realize.

Either way, we work fast and lean, relying heavily on frameworks, and following agile best practices. It’s fun.

Things we’ve built lately:

• Chicago Tribune Election Center
• Illinois nursing home safety reports
• Agent Orange spraying missions

Gear you’ll get:

• One shiny, new MacBook Pro (or an iMac, if you’d prefer)
• One CDM (Cheap Dell Monitor)
• One comfy Aeron chair
• …all at a desk somewhere in the Tribune newsroom, where you’ll be surrounded by reporters arguing with the cops, yelling about the ball game, telling crazy stories, and otherwise practicing their trade.

There is no free pop, pinball or posh cafeteria.

But, you’ll like what you do. You’ll come to work energized, and leave satisfied that you’ve done something that will make your mom proud. You’ll have held our government accountable, spoken truth to power, given voice to the voiceless, and contributed to the public good.

Beat that, Google.

Interested? Email your info to newsapps@tribune.com. Thanks!

This is more-or-less a script for an un-un-conference talk I’ll be giving shortly at ONA09.

“Imagine a news organization with only writers, and no editors. They might manage to crank out some successful stories, but without editorial controls, the failure rate would be astronomical.”
– Me, a couple of months ago.

Why we do this

You don’t adopt processes because they’re fun, you adopt them because they have special ass-saving properties. Doing it the right way may seem heavy, micro-manage-y, but when the process sings, the unbearable weight of uncertainty is lifted from your shoulders. This is freedom through tyrrany.

A seasoned developer won’t find much of what follows particularly interesting. This is elementary, but it’s stuff that seemed worth talking about…

A few baseline requirements for anyone making and releasing software

Version control

Version control software is both a safety net and a collaboration tool. It’s a place, off your machine, to keep your code, and when you update the code, it keeps your previous version(s). So, even on a one-person project, it’s essential. When your hard drive crashes, you don’t lose your work. And, when you’re working with others on a single codebase, version control gives you a central repository to coordinate everyone’s changes.

Task tracking

Task tracking is not about micromanagement (or, at least it doesn’t have to be). You’ve gotta be able to see the tasks on the docket so that you can know how deep in the weeds you really are. Also, forgetting to do something is really embarassing. You can track tasks in a spreadsheet, but that’s not very visible to the team. Instead, go low-tech — 3×5 cards pinned to the wall — or high-tech — with one of many software packages designed for the purpose.

Defect tracking

When you find a problem: log a defect. Take a screenshot, and give sufficient details to reproduce the problem. Defects are your unplanned tasks, they must be addressed — either by fixing them, or choosing to let them slide as a known defect, which is totally okay. Unknown defects, on the other hand, are the devil. Always, always record your defects, even if the very next thing you’re going to do is fix it. You *will* be distracted. You *will* forget. Defects are pickier than tasks, and are best tracked with software.

Staging environment

Like defect tracking, having a staging environment is about reducing uncertainty. It’s an environment running in parallel to production, set up as identical as you can make it to the production system. (If you’re using Amazon EC2, this is pretty much as simple as copying your production instance!) Your goal is this: knowing that, if your application works in staging, it will work in production. You can run load and performance testing against your staging environment, test your deployment scripts, and, as a bonus, it makes for a nice place to demo your work before it’s finished.

Push-button deployment

When everything is running smoothly, a multi-step deployment process (grab the latest code, ftp it all to the server, restart apache, etc.) doesn’t seem like so much of a hassle. But when the shit hits the fan, folks are freaking out, and you’ve gotta redeploy, half-drunk on a friday night, you’ll screw it up. You’ll forget something, and your minor bug will become a total clusterfuck. But if you’ve got push-button deployment, you can’t miss. If you’ve got a identical staging environment, you’re even better off, because you can develop your deployment script for staging, use it a few dozen times, and then when it’s time to roll to production, you know it’ll work.

The tools we use

• Python — Our language of choice
• Textmate — The best text editor for OSX
• pip — A better Python package installer
• virtualenv — “a tool to create isolated Python environments”
• Django — The secret sauce: a supercharged web development framework
• Fabric — Push-button deployment framework
  • Deploying Django with Fabric
  • Tools of the Modern Python Hacker: Virtualenv, Fabric and Pip
  • A recent fabfile we wrote — it’s not perfect, but it might be interesting to read
• memcached — The caching framework that makes our shit fast
• PostgreSQL — Our database of choice, primarily because of what comes next…
  • get it pre-built for OS X
• PostGIS — Gives PosegreSQL geo-magic
  • get it pre-built for OS X
• QGIS — For when you just wanna throw something on a map
  • get it pre-built for OS X — don’t forget the other frameworks!
• Amazon EC2 — Virtual servers hosted in the cloud and cheaper than my iPhone
• Unfuddle — Hosted version control, plus task and defect tracking
• Git — Our version control system of choice
  • Subversion is perfectly good too — check chapters 1 and 2 of the svn book to learn the basics.

Further reading (please, read further!):

• The craft of making software
  • Paul Graham
  • The Pragmatic Programmer

• The business of making software
  • Getting Real

• Usability
  • Jacob Nielsen
  • Usability.gov (don’t miss the guidelines!)

• Design
  • A List Apart
  • Signal vs. Noise
  • Edward Tufte

• Agile and iterative software development
  • Agile software development
  • Iterative and incremental development
  • The agile process we followed while making News Mixer

UPDATE: We’ve filled the position, but may be hiring more soon.
If this looks like your dream job, please send an email anyway.

Cross-posted from our new team blog:

We’re looking for a great hacker to join our team at the Chicago Tribune.

Requirements:

• A passion for the news
• An understanding of the inner workings of the web
• Attention to detail and hatred for inaccuracy
• A genuine and friendly disposition

And, of course…

• Bad-ass programming skills and a love for the craft of making software

Tools we use (and thus, tools we hope you might know a thing or two about — if you don’t, that’s okay, but please explain yourself):

• HTML/CSS
• Python
• Django
• PostgreSQL
• PostGIS
• Ubuntu Linux + Amazon EC2

Our team is composed of generalists: We all write GUI code, mine data and manage servers. You ought to be equally comfortable wearing many hats. That said, we’ve all got our specialities, and would love to find a team member with a superpower which none of us already possess. Something like…

• Data science (statistics, exploratory data analysis, R)
• Information design (beautiful charts, graphs and other Tufte-geekery)
• Maintaining high-performance web sites (cuz we’re gonna get serious traffic)
• Building and gardening social media or crowdsourcing applications

You’ll work closely with reporters on the investigative and city desks, helping them research and present their work. Sometimes you’ll be screen scraping, mucking with data, visualizing and exploring information, and seeking truth. Other days, we’ll huddle and sketch with reporters, imagining ways to present information and tell stories on the web.

Sometimes we’ll knock out an application in a day, other times it’ll take a few weeks. Either way, we work fast and lean, relying heavily on frameworks, and following agile best practices. It’s fun.

Things we’ve built lately:

• City Council’s $3.7 million allowance: How aldermen spent taxpayer money
• Dry cleaners’ toxic legacy: Find sites near you
• Burr Oak Cemetery: Browse the headstones
• Clout goes to college: Find how your school ranks

Folks you’ll work with:

• Ryan Mark
• Joe Germuska
• Brian Boyer

Gear you’ll get:

• One shiny, new MacBook Pro
• One CDM (Cheap Dell Monitor)
• One comfy Aeron chair
• …all at a desk somewhere in the Tribune newsroom, where you’ll be surrounded by reporters arguing with the cops, yelling about the ball game, telling crazy stories, and otherwise practicing their trade.

There is no free pop, pinball or posh cafeteria.

But, you’ll like what you do. You’ll come to work energized, and leave satisfied that you’ve done something that will make your mom proud. You’ll have held our government accountable, spoken truth to power, given voice to the voiceless, and contributed to the public good.

Beat that, Google.

Interested? Email your info to newsapps@tribune.com. Thanks!

As reported in the Chicago Tribune today, social networking is now a felony for many Illinois residents:

One law taking effect Jan. 1 makes it a felony for registered sex offenders to use social networking sites, a move aimed at taking another step toward shutting down an avenue of contact between an offender and victim.

The bill defines social networking as such:

13 		    (h) "Social networking website" means an Internet website
14 		containing profile web pages of the members of the website that
15 		include the names or nicknames of such members, photographs
16 		placed on the profile web pages by such members, or any other
17 		personal or personally identifying information about such
18 		members and links to other profile web pages on social
19 		networking websites of friends or associates of such members
20 		that can be accessed by other members or visitors to the
21 		website. A social networking website provides members of or
22 		visitors to such website the ability to leave messages or
23 		comments on the profile web page that are visible to all or
24 		some visitors to the profile web page and may also include a
25 		form of electronic mail for members of the social networking
26 		website.

Sure, it seems right to stop violent criminal perverts from poking around MySpace, but every damned site on the web is integrating social networking features nowadays. Is it offensive to the public interest if a sex offender shares an article on TimesPeople? What about LinkedIn? Do sex offenders not deserve a place to post their resume?

Or, what about a social network devoted to sex offenders trying to rehabilitate? If there isn’t a Ning for this already, there sure oughta be.

This is bad legislation. Sex criminals have rights too, and this law effectively bans them from the Web.

For the folks who missed the show, here’s a quick rundown of what we talked about. (I am sad to say that there is no way to serve refreshments through the web, so to get the full experience, you’ll have to get your own punch and pie.)

PolitiFact’s Obameter

Reporters and editors from the [St. Petersburg Times] fact-check statements by members of Congress, the White House, lobbyists and interest groups and rate them on our Truth-O-Meter. We’re also tracking more than 500 of Barack Obama’s campaign promises and are rating their progress on our new Obameter.

Tampa Bay Mug Shots

Our goal is to provide a complete profile for individuals booked into jail in Pinellas, Hillsborough, Manatee and Pasco counties. A complete profile on Mug Shots constitutes: name, photograph, booking ID, height, weight, age, gender, eye color, birth date, booking date and booking charge.

ChangeTracker

ChangeTracker watches the White House’s web site so you don’t have to. Whenever a page on whitehouse.gov changes, we’ll let you know — via E-mail, Twitter, or RSS.

Filibusted

Some senators like to filibuster and keep the majority from having their way. You might think they’re heroes. Or jackasses. Either way, they’re worth keeping track of.

Represent and Repsheet

RepSheet lets you…

• look up your elected representatives…
• see the political zones you live in…
• and track news about your reps.

Investigate your MP’s expenses

Join us in digging through the documents of MPs’ expenses to identify individual claims, or documents that you think merit further investigation. You can work through your own MP’s expenses, or just hit the button below to start reviewing.

Many Eyes: Word tree and US Gov’t Expenses chart

Many Eyes is a bet on the power of human visual intelligence to find patterns. Our goal is to “democratize” visualization and to enable a new social kind of data analysis.

Names, Lists, Photos, Stories - California’s War Dead

Military deaths in Iraq and Afghanistan, 2001-Present

Know thy Congressman

“KTC” is a bookmarklet that displays an abundance of political and biographical information about current members of the Senate and House of Representatives.

Watching the Growth of Walmart Across America

Yesterday I quickly put together my own Walmart growth video using Modest Maps. It has the usual mapping features - panning and zooming - while you watch Walmart spread like wildfire. It starts out slow with the first location in Arkansas in 1962 and then spreads vast in a hurry.

The schedule for ONA09 is jam-packed with shiny stuff — social networks, mobile tech, they’ve even got Leo and Ev! Great. But the reality is that Twitter will not save the news, just like chrome rims can’t save General Motors.

We can talk about technologies, tools and innovators all weekend long, but it won’t help if news organizations don’t understand the basic principles of software development. So, if anyone out there is interested, I’d like to arrange an un-conference to talk about some un-shiny, boring-ass shit: software development methodologies.

Topics of import we might address:

• Version control
• Task and defect tracking
• Goals, use cases and designing with your audience in mind
• Working iteratively and being agile

Code is not something you can slap up like wallpaper. Making software is a craft. It requires discipline and skills far beyond a superficial awareness of the technologies available. At every moment of the process, from conception to release, there are right and wrong ways to make software.

Imagine a news organization with only writers, and no editors. They might manage to crank out some successful stories, but without editorial controls, the failure rate would be astronomical. From what I’ve learned in my (admittedly brief) time in this industry, this is the state of software development at newspapers — it’s failure-ridden, amateurish and ad-hoc.

Let’s do it the right way

Over the years, lots of clever people have studied the craft of software development, and come up with battle-tested tools, best-practices and processes to reduce the failure rate and better-ensure success. I learned a thing or two about these methods in my previous life, and would love to share.

So, I’d like to set up an un-conference session. We’ll get a room and a projector and talk process. Who’s interested in attending? What topics would you like to see addressed? Would anybody else like to present?

(If there’s no response, I’ll shut up and go back to work — but if I’ve convinced you, please leave a comment. No comments, no un-conference.)

I don’t write about it much here, but I love the radio. NPR is my primary daily news source. So, I was totally geeked when Here and Now asked me to be on their program. And through the magic of editing, I think I managed to sound pretty alright!

(You know how, when someone gets under your skin, but you’re so worked up all you can say is “Oh yeah? Well, your momma!”? And then later, when the moment is gone forever, your brain catches up and comes up with all sorts of erudite, polysyllabic arguments? Radio is like that.)

Best part about the radio bit? All the old friends who emailed me after they heard the program, including one of my favorite high school English teachers. Dunno if/when the web will have that kind of reach. Love.

“…part of a hegemonic institutional perspective that is glaringly…”

Back online, my Hackers wanted! bit on O’Reilly Radar got a lot of attention, mostly hating on journalism and grumbling about needing a bachelors degree before pursuing a masters degree. But I’m hopeful that the message got through to a few programmers who want to make the world a better place.

In retrospect, I should have probably explained the importance of journalism in a democratic society, and ceded that yes, journalism is mostly broken right now, but this is our opportunity to fix it. Hindsight. Le sigh. If you’re into it, check the comment threads on the original post, and the nerdy aggregators that picked it up:

• O’Reilly Radar (original post)
• Digg
• Reddit
• Hacker News

S’pose if you’re not pissing somebody off, you’re doing it wrong. Right?

Rich Gordon, the fella who decided it was a good idea to bring coders to J-school, wrote a response on Idea Lab including an interview with my new boss, Digital Editor at the Chicago Tribune, Bill Adee.

I even got ripped off completely by Tech Crunch, where fellow Medill alum Leena Rao summarized my post and completely failed to mention where she got the brilliant idea — eliciting 85 comments. Thanks for not linking!! Love!

But as far as I can tell from Wolfram’s recent presentation at Harvard, Alpha will tell you the source of the data, and will sometimes show you an example formula for a type of calculation (how to figure the volume of a cylinder, etc.), but it will not show you the actual calculations necessary to arrive at the answer.

Instead, we’re supposed to trust the system. Alpha’s code is so complex, says Wolfram, that it would be vastly inefficient for a mere human to read the steps. The more sensible approach is to “try to do the best QA that we can.” (QA = quality assurance, a.k.a. testing) And I’m certain that he’s right — that thing has got to be a bear to test.

If your mother says she loves you, check it out

The problem is, if I want to use Alpha’s answers in a news article, scientific paper, or anything else requiring an authoritative source, I need to know that it’s right. Unless we arrive at some kind of universal agreement among scientists, academics, mathematicians, and everyone else that Wolfram’s creation is always right, I can’t believe Alpha’s answers if I can’t test them.

I’m baffled by this omission. Alpha can do extraordinarily complex work, but it wouldn’t pass high school physics. You’ve got to show your work! Scientists validate hypotheses by repeating experiments and comparing the results. “Trust me” is not an authoritative answer.

“An authoritative source for data” is misleadingly simplistic. If it does what it’s supposed to, Alpha is more like “an authoritative source for quantitative thought” — the ultimate almanac, complete with a staff of uber-geeks from every field worth researching, backed by machines capable of turning around complex calculations in microseconds.

It’s cool as hell.

It’s a pocket calculator for *everything*.

It’s the realization of Leibniz’s characteristica universalis.

But is it correct? Only one way to tell. Mr. Wolfram, will you please show your work?