Apr 122013
 

On Saturday, April 6, I had the pleasure to go to Minnebar 8.  Minnebar is a free-to-attend, volunteer-run "unconference" put on by the Minne* organization.  It was very good, and I highly recommend attending the next Minnebar if you are in the area.  Minnebar focuses on the intersection of the high-tech, start-up, and social-outreach communities in the Twin Cities.  This was the eighth annual version of the Minnebar gathering and it was held at the Best Buy corporate headquarters in the south Minneapolis metro (Best Buy donated the space).  Over a thousand people were registered for the gathering, and from my view in the middle of the crowd, that seems like a reasonable estimate of how many actually attended.

There were sessions scheduled throughout the day much like for any conference you might go to.  There were probably 10 or so parallel tracks going, so there was always a selection of topics.  The sessions were 40 minutes long, and consisted of presentations about the topic at hand by one or two presenters.  The presenters tried to take a conversational tone with their crowd, making it more of a dialog.  Most sessions were very good.  Here is an outline of the sessions I attended:

  • Teaching Kids to Code.  This session discussed a new Coder Dojo starting up in the Twin Cities (link).  Coder Dojos are distributed volunteer organizations that are currently springing up across the world focused on getting K-12 kids interested in programming, especially kids from groups that do not typically pursue computing careers.  They do this by hosting learn-to-program type events with a bunch of volunteer professionals to take the scariness out of coding, and provide the kids with a great experience.  Outreach efforts are extremely important for the creativity and vitality of the profession, so I really hope it takes off.
  • Agile Financial Modeling.  This session was about putting together a quick and dirty financial model for a fledgeling company.  I went because I have a fledgeling company, and had never heard of financial modeling before (it is essentially a codified way to sketch out projected estimates of income and expenditures over a year or three).  I found the session informative, and the layout they gave for the models is more intuitive to build and use than the one I had rolled myself for my own operation.
  • Managing Your IT Career.  This was a great session by a local headhunter about the state of the high tech labor market in the Midwest.  In short, the market is good for pretty much any computing professional.  The Twin Cities is a good place to be.
  • Civic Hacking.  This was a session put on by Open Twin Cities, a local group devoted to ultimately getting structured, real-time access to government-collected data so that community members can use it to improve the local community.  This group seems to be focused on software development with local hackathons and the National Day of Civic Hacking.  I think this is an interesting idea, and I can't wait to see what comes of it.
  • Percolating Trep Net.  To be honest, I am still not quite sure what this session was about.  There was talk about the different social networks people have, both online and off.  There was some information about categorizing these networks and people in them, but I never did figure out what the end result was supposed to be.  I guess it was for people with a different educational background than I.
  • This Old Website.  This was a really great session about adding HTML5, CSS3, and Responsive Design to an existing website.  They covered all three topics very quickly, and very well given the time constraint.  Participating in this session was akin to drinking water from a fire hose.  As someone whose web design tends to be pretty ad hoc (just see Birdseye College Price Comparison for an example), a lot of what was presented is very applicable to me.  They even put their slides online here.
  • Technology Behind the Obama 2012 Campaign.  This was a great final session for the day.  It was put on by a developer who worked on the information infrastructure behind the Obama 2012 Campaign.  It is absolutely amazing what all they were able to build, deploy, support, and then tear down in under a year and a half.  Political campaigns these days need a massive amount of software providing a variety of different functions to different groups of people.  The Obama Campaign built their software on Amazon Web Services, which was a fantastic choice for this type of operation--they only need the massive data center for a relatively short,  fixed time period, cloud services can adjust to exponentially exploding usage as the end of the campaign nears, and cloud services can be readily replicated to deal with parts of the infrastructure going down.  Overall a fascinating look into what it takes to run a modern political campaign.

As can be seen from the list above, there was a very diverse range of topics covered at Minnebar 8, most of which were very exciting.  Food was also provided, and it was delicious.  We got Pizza Luce (a local gourmet pizza chain) for lunch.  Beer was also provided for a social meet-and-greet at the end of the day.  What more could you ask for?

Overall, Minnebar 8 was an excellent experience.  It is astounding and heartening to me that a conference of this quality and magnitude can be organized and delivered in a completely volunteer manner.  It was very cool and very impressive.  I will definitely try to attend next year.

 

Apr 052013
 

I recently finished a cover-to-cover reading of Frederick Brooks' classic book on large software project management, The Mythical Man-Month (TMMM).  Originally published in 1975, TMMM details Brooks' management philosophy, which he developed as manager of the IBM OS/360 operating system from 1964-1965.  I read the 20th anniversary edition (published 1995), in which two additional chapters were added that update the philosophy put forth in the original edition from the beginning of the timesharing era up to the PC era of computing.

My impression of TMMM is very positive overall; it is easy to see why this is still a required text on software project management, even nearly 50 years after Brooks finished his stint managing the OS/360 project.  There are many interesting anachronisms in TMMM that would necessitate a history lesson in computing for today's college-age audience, e.g., software development in pencil and paper (since machine time was rare and expensive), separate punch-card readers from computers, development primarily in machine code, a preoccupation with memory size of programs, a view that structured programming might be a good idea that likely goes too far, etc.  Clearly, a very different world technologically than that which we work in now.  But despite all the differences in computing technology from 1965 to today, the fundamental problems in large software projects and the structural solutions to combat them that Brooks presents have not changed all that much.  It is rather fascinating--when I was teaching, there were always a few students who went into conniptions if an assignment required them to use a terminal interface instead of a graphical IDE, a 10 year change in development habit historically.  But current techniques for building large software systems remain fundamentally quite similar over 50 years of computing history.

In TMMM, Brooks posits, quite rightly in my opinion, that conceptual complexity is the primary hindrance to quick and quality software development.  In addition, conceptual complexity is a problem that can never be truly solved.  Conceptual complexity here means the number of logical components in a software system coupled with the the amount of communication required between these components. Because of the complex interrelationships between the components, a particular component could interact with hundreds or thousands of other components, requiring a huge amount of communication overhead between the people building these components.  This communication eats up a lot of time for the people involved, which in turn requires more people to get the project done in a timely manner, which in turn adds more necessary communication...and so forth.  The cycle is recursive.  The curse of complexity is that at some point, when more people are added to a project, the amount of time the project takes actually gets longer, instead of shorter.  This is why big software is almost always late and over budget.

Brooks presents a number of management techniques in TMMM to tame the overhead brought on by this complexity.  Many of these are standard industry practice today for large projects:  Brooks recommends having a rigidly hierarchical top-down design and development process, a chief architect at whom the buck stops for design decisions, a separation of implementation from design, teams dedicated to testing and finding bugs, a team dedicated to keeping documentation up-to-date, keeping track of the project through document maintenance, starting the design with a user manual/model, source control, and regression testing.  Brooks also presented some ideas that are not really used today, including his small "surgical team" concept, an insistence on the Waterfall design method (which he renounced in the 1995 retrospective chapter), and fairly hands-off upper management (which might exist somewhere?).

While reading TMMM, it seemed to me that Brooks had an idea of future developments that actually did eventually show up.  This includes documentation contained within the source code itself (Javadoc and the like), Git-style version control, a Wiki-like system for managing project documents, and in some sense Agile development (at least for individual components).  While reading through the original chapters, I noticed a few places where Brooks hinted at object-oriented-like abstraction, but in the 1995 retrospective, he claimed to have not seen that coming.  Brooks consistently reads as being ahead of his own time throughout.

As Brooks points out in TMMM, large software projects are the most complex things that humanity has ever built, and this complexity makes them very difficult to build on time and on budget.  Further, we have collectively already solved most of the easy problems in tackling the software project overhead, which means that most of the time spent on large software projects now is simply inherent to the problem being solved.  But despite this, TMMM ended on an optimistic note:  we may not ever solve the tractability problems in building large software, but we continue to build large software, producing ever more wondrous marvels of human ingenuity.