MemBrain

With the help of John Dugan and Tim Lowrimore of Coroutine, I've been working on starting a new software group here in Memphis. The idea initially was to start a "users' group", but I wasn't too happy with that mold. There are already a few user groups in Memphis, and I didn't want to limit the topics of conversation to a single technology. Furthermore, I really want a group that's collaborative and engaging, not just a lecture series.

I decided to model our effort somewhat after the Silicon Valley Patterns group, a few meetings of which I attended when I was living in the south bay. Though SVP tended to be more academic, I really enjoyed the level of discussion as well as the informal structure and atmosphere. Also, I appreciated the way the group did different tracks, each covering a unique and interesting field of technology.

So, with a general sense of what we wanted to initiate, a group of 7 or 8 of us met last Wednesday evening and established the MemBrain group! Our first track will be Ruby on Rails (surprise, surprise) and we will spend the next three Wednesday evenings building a web app that will show you interesting things about the folks to whom you are connected on Twitter.

If you want to learn more, you'll just have to join us next Wednesday, June 24th, 5:30PM at the EmergeMemphis building in downtown Memphis!

Or, you can check out the group's new website: http://membrain.ws

My new gig

Today, an announcement: I have a new job!

After leaving eBay/MicroPlace at the beginning of March, I've been looking at several opportunities here in Memphis; some entrepreneurial, some not so much.  For months I have been helping various entrepreneurial groups and doing my part to encourage more startup software development in Memphis.  One such group I've been collaborating with is RocketFuel, a local web design and development firm.  Having gotten to know the RocketFuel team over the past several months, I've been very impressed with the team's culture and accomplishments.  They have developed a proprietary Content Management System that provides a wonderful balance of design excellence and truly easy site management.

The RF leadership team and I started discussions some weeks ago and I'm proud to annnounce that, as of Monday, June 1st I will be the new Chief Technology Officer for RocketFuel!

The team and I have had some very positive strategy sessions already and I'm really excited about the opportunities ahead.

Software Development Bookshelf

I was perusing the software development section of the Memphis library today and, guess what?  The selection was really bad.  Not too surprising, but I feel compelled to try to change that.  I strongly believe that software and web-based development are incredibly empowering areas of technology.  Anyone with the smarts and determination to build something can do so.  The game has changed such that you don't need a lot of money to get started anymore.  You just need the willpower to learn.

With this in mind, I conversed with the girls at the science desk and they enthusiastically agreed to take a list of suggestions for adding to the collection.  Below is what I put together.  I can't really tell you what my theme is, other than to say: if I was a beginning programmer, below is the bookshelf I would want made available to me.  None of them are beginner books, but that's not what I would want.  I would want a list of books that lay out the master craft I should aspire to.

I only selected a few choice language books.  Why?  I'm not sure, other than to say that I'm no longer interested in reading any books about Java and Visual Basic, nor is there a need (from what I've seen) for books about Java and Visual Basic at my public library.

Lastly, this list is not meant to be exhaustive (of course).  It feels like it strikes a nice balance between the breadth and depth of the subject at hand, while staying small enough to actually get added to the library's collection.  Furthermore, I deliberately left off a couple of titles that the library already owns (woefully few, though).

What do y'all think?  Please make additional suggestions (or flame mine) in the comments:

Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series)

by Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides

-------------------

Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series)

by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

-------------------

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) 

by Frederick P. Brooks

-------------------

The Pragmatic Programmer: From Journeyman to Master 

by Andrew Hunt, David Thomas

-------------------

Peopleware: Productive Projects and Teams (Second Edition) 

by Tom DeMarco, Timothy Lister

-------------------

Extreme Programming Explained: Embrace Change (2nd Edition) (XP Series)

by Kent Beck, Cynthia Andres

-------------------

Code Complete: A Practical Handbook of Software Construction (Paperback)

by Steve McConnell 

-------------------

Refactoring to Patterns (Addison-Wesley Signature Series) 

by Joshua Kerievsky

-------------------

Test Driven Development: By Example (Addison-Wesley Signature Series)

by Kent Beck

-------------------

User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series) 

by Mike Cohn

-------------------

Working Effectively with Legacy Code (Robert C. Martin Series)

by Michael Feathers (Author)

-------------------

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)

by Robert C. Martin

-------------------

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series)

by Martin Fowler

-------------------

The C++ Programming Language: Special Edition (3rd Edition)

by Bjarne Stroustrup

-------------------

The Ruby Programming Language

by David Flanagan, Yukihiro Matsumoto

-------------------

Agile Web Development with Rails, Third Edition

by Sam Ruby (Author), Dave Thomas, David Hansson

-------------------

Rails Recipes (Pragmatic Programmers)

by Chad Fowler

-------------------

Programming Python

by Mark Lutz

-------------------

Python Cookbook

by Alex Martelli, Anna Ravenscroft, David Ascher

My first iPhone game

I've been staying busy recently collaborating with several folks on some interesting software initiatives, as well as a couple of my own ideas.  One in particular kept me in "hermit" mode for the first couple of weeks in March: my very first iPhone game!

I downloaded the iPhone Software Development Kit and had my app finished in about a week.  However it took several weeks for Apple to approve contracts, process my account registration and work through all of the other red tape that's necessary to get started with them.  In the end, though, my app finally made it to the store for sale!

It's a simple puzzle game variation of tic-tac-toe called Tic-Tac-NO!.  I've got several other game ideas I want to work on -- if I can find the time.

Big thanks to Caitlin for pointing out that it was finally showing up in the Apple app store (and for being my very first customer!)

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.