Games as AI Research Tools

Through my work with the Cognitive Computing Research Group at the University of Memphis, I've come to have a great appreciation for the challenges facing researchers and developers pursuing a generally competent AI system, also known as Artificial General Intelligence (AGI), or "Strong AI".  AGI differs from traditional AI research in its goal to achieve AI systems that, through learning and adaptive architecture, can be applied to any domain.  This is as opposed to classical AI initiatives (both symbolic and connectionist) that have been historically targeted to solving particular problems in specific domains.  Because the animal brain is the best example we have of a generally intelligent system to date, AGI work is usually heavily inspired by cognitive science and neuroscience research.

One of the challenges with AGI research is the holistic nature of the goal: it's nearly impossible to make significant progress by narrowly focusing on a single aspect of cognition.  Perception/recognition, actions/behaviors, emotions/pleasure/pain, memory, consciousness/metaconsciousness/self-awareness are all integral components of the cognitive process.  Because of this complexity and interdependence, some researchers espouse the embodiment argument, which states that an AI system must be situated in some physical (or physically simulated) structure to achieve true cognition.  The argument is that, for animals, the body plays such a critical role in shaping cognitive function that it will be nearly impossible to replicate successful cognition in computational systems without including some type of body implementation.

Historically, researchers have turned to robotics to satisfy their embodiment needs.  I, however, am a fan of simulations, which have many advantages (including cost and simplicity) over hardware robotics.  Furthermore, I believe that relatively simple simulation systems such as gaming frameworks could provide an excellent testing ground for various cognitive theories.

Imagine a cognitive implementation of the mind, where each item in a low-level sensory array (think of groups of nerve endings in your hands, or the optic nerves in your eyes) was simply assigned to parts of a 3D model in something like the Unreal Engine.  When the 3D model encounters objects in its simulated world (by bumping into them, or having them enter its field of vision) it can select and perform actions in the world, creating the feedback loop necessary for learning to occur.  The complexity of the arrangement could easily be scaled up or down as one's  research dictates and hardware capabilities allow.  Furthermore, the simulator could (and should) be built in a decoupled way, such that the cognitive implementation (the "brain") could be unplugged and easily swapped with another in order to test various implementations.

Think it sounds silly to use games for serious research?  Cyril Brom, from Charles University in Prague has in fact already pursued significant research along these lines.

Small business incubation

As the whole world looks at how (and if) the United States can stimulate our national economy, I contend that we should place more focus on small business incubation. I mean "incubation" in a specific sense very different from the funding for Small Business Administration loans that are in the current version of the bill. These are good, but target a very different business model than what I have in mind.

Below, I lay out a vision for a business incubator that I would very much like to see happen in economically challenged urban areas around the country (places like Memphis, Cleveland, St. Louis, Detroit, etc). I strongly believe that there is an opportunity for software-focused business models to thrive in non-traditional areas of the country and have an enormous positive impact on these regional economies. Silicon Valley is great (I've lived there), but we need to pollinate other parts of America with the same entrepreneurial focus and brilliant innovation that has made Northern California the wonderfully affluent place that it is today.

The type of businesses I see being incubated by this system are small, lucrative software products such as commercial applications, websites and web services.  This business model was presented very succinctly by David Heinemeir Hansson at Startup School 08.

So, here's my outline for a small business incubator: 

1. Targeted at early stage software/web-based business ideas
• Can be launched by very small teams (1-5 people)
  
• Low capex/startup costs ($50k-$200k)
2. The incubator is managed by a well-balanced board of technologists and entrepreneurs with expertise in software, electronic commerce, business development and legal.
   
3. Stage 1: Apply for proof-of-concept grant (~$10K)
• Establish the project's viability within 4-6 weeks (the shorter, the better) by using these funds to:
  
• Refine the business plan
• Create a technology roadmap
• Design and build a prototype
• This initial $10K is not a grant or funding round: it is a promissory note tied to the applicant's active participation in the project. 
4. Stage 2: Present the business plan and demo the prototype.  A review board decides go or no-go.
   
5. Stage 3: Iterative, quarterly funding cycles (~$25K-$100K) covering operating costs
   
• Provide shared office space and resources (like a traditional tech incubator)
• Each team works regularly with a team of mentors: one technology expert, one product expert.  Mentors provide guidance to their respective team members and work together to help the group manage the project
• Regular status updates every 30 days to the review board
• Demo of new product development (required)
  
• Progress plan update and estimation of progress milestones for next status update
• Review board assesses previous estimates and current updates to gauge the team's success, foresee problems and commit to next quarterly round of funding
• Each funding round gives another slice of equity to the incubator, in accordance with a predefined schedule
  
6. Stage 4: Launch or scrub within 6 months (the shorter, the better)
   
7. If the project is scrubbed, this is okay; promote idea of failure as a learning opportunity
• Require "drop outs" to participate in a post-mortem activity (participation in this final stage will satisfy the terms of the stage 1 loan)
• Use feedback gained in these post-mortems to guide future activity (both for reviewing new business proposals and managing ongoing projects)
  
8. Inactive, ineffective or disruptive mentors or board members can be censured or ejected, as necessary
   

This process is designed to fail fast.  Unlike traditional investment banking and venture capital models, the goal is to quickly incubate lots of small businesses with an expectation to get several multi-million dollar successes.  Rather than pour millions of dollars into a handful of businesses in the hopes that one will be a billion-dollar lottery ticket, this model is designed to give birth to many small, successful businesses that can have a long lifespan.

There's certainly nothing wrong with the traditional VC model -- especially from the investor's perspective.  A big win using the conventional model will almost certainly generate more wealth for the venture firm.  The small business incubator, though, will have a much broader impact on a community scale.  Imagine the turnaround that could happen in a depressed local economy if 30-40 small businesses could be established over the course of a couple of years, each one employing 10-20 people and earning some millions of dollars of annual revenue.  Now compound that success over several annual cycles and you begin to see a picture of robust economic growth.

Software is a minefield

In Software Development, there are a number of good practices that often go, well... unpracticed. Testing (never mind the masterful arts of test first or behavior driven development), pair programming (or continuous peer review, if you prefer), good design (including the application of design patterns) and continuous refactoring come to mind immediately.

The reason these practices are forsaken is clear: "I don't have time for that." This attitude pervades most activities of typical software teams. Management pressure, scope creep, deadlines (real and imagined) all lead to a constant sense of urgency and temptation to cut corners. I believe this is due to a fundamentally flawed perception that a software project is a race. This is wrong; it's a race through a minefield.

We are racing, of course -- against competitors or deadlines or a closing window of opportunity. However, the circumstances of the race are such that it's not a good idea to simply run as fast as you can. For a while, it may feel as if you're making great progress. But this is a false sense. When you hit a mine, the resulting setbacks will be devastating to your overall progress.

Instead of simply running as fast as possible, the correct attitude is to move with deliberate speed.  After all, we are racing, so we want to move as fast as we can.  But we really need to be sweeping mines as we go.

So why isn't this deliberative approach more prevalent?  Unfortunately, teams can be awfully good at denying the truth behind a project's demise.  Failure is an orphan and it's easy to obscure reality by pointing the finger at something -- anything -- other than the fact that we, ourselves, didn't keep things well-maintained.

The good news is that if you do what you should be doing (testing, designing, refactoring, talking) when you should do it (right now), ultimately you will arrive at your destination much faster than your competition.  That is, unless your competition has already started focusing on quality while you're busy running towards that land mine.

"An electronic run on the banks"

I'm no conspiracy theorist (really), but here we have a member of the U.S. House of Representative saying that sometime around Sep 15th, 2008, some entities drew down $550B worth of money market account assets over the course of an hour or two.  Best estimations are that, unchecked, this would have caused an irrevocable worldwide economic collapse over the course of the next 24 hours.

(The bad news starts at 1:53)

So, are we to believe that millions of Americans woke up that day and spontaneously decided to clear out their money market savings over lunch hour?  Otherwise, this begs one question: who did?

It does, however, explain much of the panic-mode reactionary policy of the last few months. Looks like the bank bailouts were, indeed, more about preventing short term economic nuclear meltdown than long term stimulus.  I just wish these policies were being implemented more openly.

Acknowledgments: big thanks to wilkes for linking me to this.

I am a mid-core gamer

Some time ago, I stumbled across the guys at 8bitrocket and their Mid-Core Gamer Manifesto.  I immediately related to the profile they've put together.  For the most part, this perfectly describes my current gaming inclinations: too busy with daily life to be a hardcore gamer, but more interested in compelling, immersive gameplay than the typical casual gamer.

With the emergence of new, unconventional gaming platforms (like the iPhone), I really think the mid-core gamer crowd presents some great market opportunities.

Fighting crime in Memphis

My wife and I attended the town hall meeting on crime last Saturday, and left with two specific calls to action on how we can help fight crime in Memphis.

First, it's clear that tougher sentencing laws are needed for crimes committed using firearms.  In Florida, such laws helped drive down violent gun crime by 30 percent!  Call the Governor and urge him to support passage of such legislation.  Follow the Midtown Security Community blog and Operation Safe Community for more info on this legislative effort.

However, there is a roadblock in Tennessee for passing such laws.  There is a mandate requiring funding for any bill before it can be introduced to the assembly.  In principal, this is a great idea.  It should help avoid overspending and budgedt deficits.  However, it can also be used to block legislation without debate.  According to Shelby County District Attorney General Bill Gibbons, the fiscal note estimating the cost of newer gun sentences is $73 million.  Where did that figure come from?  No telling, because the research for these fiscal notes is done behind closed doors.

We need to amend the current legislative mandate requiring fiscal notes for all bills introduced to the legislature and require sourced and cited accounting behind these notes be made public.  Otherwise, tacking on a prohibitive fiscal note to a bill is an easy way of killing it without taking a public stand against it.

Stimulus info

No one's thrilled about the prospect of adding $800B to the national debt, but I am glad that we'll be able to track the spending via this site:

http://recovery.gov

Transparency is a very good thing.  It would, however, be great to see the administration follow through with the "sunlight before signing" campaign promise and provide easy access to information on these bills prior to their passage.  I had a tough time finding a good summary of the current bill's spending breakdown.

However, I did find the following on CNN (and it's already a little out of date):

$300B+ - Tax cuts for individuals and businesses

$142B - Education infrastructure (FYI, experts estimate this is a fraction of what is needed simply to repair existing schools)

$102B - Benefits: Boosting payments for unemployment, COBRA and food stamps

$90B - Construction, including roads and mass transit

$87B - Medicaid

$54B - Energy: Upgrade national electrical grid, expand alternative energy production, weatherize/modernize buildings

$20B - Health care: Modernize/computerize records systems

$16B - Technology/science, including expanding broadband

$4B - Law enforcement

Unit tests are (generally) very useful

This post from a few days ago, which argues that unit tests are not useful, has generated a spirited debate, and I wanted to chime in.

Without a doubt, Unit tests are (generally) extremely useful.   I realize that one can find examples of trivial code or toy problems for which unit tests wouldn't provide much usefulness, but such pedantic arguments aren't very helpful.

The author of the post above claims that unit testing isn't useful because it doesn't find bugs.  Many commentors have already pointed out the fallacy of this argument, namely that unit tests aren't supposed to find bugs, they are supposed to prevent them.  The author then backtracks saying he meant pre-release bugs, but his examples of activities that he feels find bugs more effectively are almost all post-release activities (user reports, monitoring and logging).  Even load testing is post-release in my opinion, because I consider code I write to be production ready whenever I release it to QA.

This is one of the major benefits I personally gain from unit testing: confidence.  Having a comprehensive suite of unit tests allows me to both code new functionality and (as importantly) refactor existing functionality and drastically reduce the risk that I will unwittingly break pieces of the system.  I really can't imagine doing continuous refactoring without unit testing.  I can, however, imagine not doing any refactoring at all, because I have lived in that particular circle of hell and don't wish to visit again anytime soon.  Building up such technical debt is the usual destination for shops that don't do automated unit testing.

If you're really good, test driven development provides a confident basis for both code's design and implementation.  Forcing oneself to stop and think of the design and interface to a piece of functionality before coding its internals leads to much better organized software and a more solid design overall.

This whole debate highlights a major perspective problem I've seen in other software shops in the past: the "code and fix" mentality.  This attitude (well represented in the above blog post) says that the programmer's job is to simply write code (and maybe do some design work every now and then).  This narrow view of software development is prevalent in the industry and is the reason behind the generally low quality of much software being released.  If you're in management and hearing this argument from your techology team, you should take a look at how much you're spending on that army of QA staff, then look at the overall quality of your system (measured by number of defects in production).  Having done this,  it becomes be pretty clear whether or not to reject such arguments with a vengeance.

Bad News vs. Bad Information

The subtitle of this blog is the title of a Modest Mouse album, but the inspiration for using it was a bit of wisdom I learned from a friend of mine, Julio Santos. It goes like this: make sure you understand the difference between bad news and bad information. Bad news can actually be good, but bad information is never good.

What's so great about bad news? Consider that bad news is simply the act of learning about bad circumstances. You can't change the fact that something bad has happened, but you do need to know about it if you're going to respond to it. Bad information, in this context, is simply thinking that things are peachy when they are not. This may feel blissful, but not for long. Ignorance is a painful navigator.

If you're really good, you look for bad news early and often. The sooner you learn about a problem, the sooner you can do something about it. Most problems don't go away over time -- they get worse.  Avoiding this situation is definitely a best practice.

In software, there are several strategies one can use to increase the bad news:bad information ratio.  Regardless of one's role, it's all about increasing communication.  Developers, increase the flow of communication from the codebase.  Automated unit tests, a continuous build system and metrics gathering will go a very long way towards giving the team a clear view of where things stand.  Business teams, demand to see working software delivered and demoed on a regular basis.

In general, increasing communication between the stakeholders (end user, customer, etc) and the technology team (developers, UI designers, testers, etc) is critical.  Have a stakeholder work alongside you who can answer specific questions about how the final deliverable should function.  Shrink the feedback loop in all of these efforts and work iteratively and incrementally.

This may all sound like common sense, but people opt for bad information over bad news all the time. The metrics one chooses to pay attention to, the language (especially body language) one uses, and most importantly the questions one asks all determine your level of informedness.  Remember, no news is not good news -- it's the worst kind of bad information.