I'm used to reading about VIm plugins and tips on sites like http://www.vim.org/ but I never really thought about the power of collaborating on the ultimate VIm config via the forking, pushing and pulling that is github.  The idea of forking someones config and :%s/leader='\'/leader='`'/g is really compelling.

So I got to my next session, Philly Opendata, a bit early and powered up the University of the Arts guest wireless to see what this gitHub dotfile concept is really about and could not connect. After an hour of discussing how VIm keeps your hands on keyboard and head focused on the task I'm again reduced to a mouse clicking consumer wondering where the button is that will get my osx to work, or give me a clue as to why it won't.  I would have searched for "iwspy on osx" but without wireless it would have been a short trip.

The point of this segue is that Maurice noticed my plight and leaned over with the security settings to his mifi app to get me out of the 80's.   That has never happened at any formal show I've been to.  He had signal and was willing to share.

Turns out Philadelphia has data and is also willing to share.

Getting access to this data is important for so many reasons.  Before I talk about the social importance of opendata I have to step back and comment that crunching huge datasets and experimenting with bizarre visualizations is the type of fun that drew me to computers in the first place.  Whether plotting Fourier power transforms of breathing sheep or number of potholes per coffee shop there is something exciting about creating a unique perspective on otherwise boring or overwhelmingly complex data.

Having transparency into our government machine is really just a continuation of our need for independent newspapers.  Thomas Jefferson is often quoted as saying that Democracy depends upon an informed population.

The city of Philadelphia has committed to releasing 311, GIS and crime data. There was a very lively discussion at this session around the types of apps we could build, the benefits that the city will reap and most importantly WHEN it will launch.

This was all good and exciting conversation and one particular thread stuck with me long after the session ended.  We talked about how we can audit the data and ensure that it is used properly and not abused.

We live in an age when a comedian can save the elephants by editing a wiki page.  When I was a kid I was raised to believe that reporters were 'investigative journalists' and dug deep to get the facts.  I grew up just a few miles from where Geraldo Rivera got his start with an acclaimed expose of a mental institution that resulted in action being taken.  I was not until I got older and became exposed to Fox and the Daily show that I'd realized how seemingly sane people could look at the same data information and draw such dramatically different conclusions.  (Actually I learned that in grad school.  "Number-smithing" and "creative graphing" are required classes for practicing engineers.  There was a similar class for the business students, but it skipped the numbers part altogether.)

It would be really easy for me to take all the pothole data and plot it on google maps.  A little massaging could show my street as having a few extra's and maybe I'll even 'fix' a few in the other neighborhoods.  People will see my app and maybe my street gets a little bump in priority.

Visualization is a powerful tool and data of this magnitude will always be analyzed with bias.  Even a simple flow chart describing the new health care policy can be warped towards an agenda.

Opendata puts us all on a level playing field.  I'm looking forward to the apps and visualizations coming out.  I will be disappointed if we wind up with a  liberal and a conservative app mirroring our polarized two party system.  I personally feel that there is a responsibility in the hands of the designers and developers to attack this data and ensure that the people of Philadelphia have multiple avenues of getting accurate facts.

The first tenant of the IEEE code of ethics hints at the damage we can do here.

1. to accept responsibility in making decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment;

As far back as the 12th century the Rabbi Maimonides wrote a Physicians oath with another line that I find appropriate:

May the love for my art actuate me at all time; may neither avarice nor miserliness, nor thirst for glory or for a great reputation engage my mind; for the enemies of truth and philanthropy could easily deceive me and make me forgetful of my lofty aim of doing good

A Doctor's specialized knowledge and training puts his actions and opinions under a special light with regard to ethics.  Typically computer professionals live by a 'do no harm' credo as well, but our actions were usually bounded by our working domain.  With open data and blogs we can now use our skills and training for the betterment of democracy or as a lever to move a personal agenda.

Now that I am ready to wield this data in the name of Democracy and Truthiness I'm headed over to listen to Tom Janofsky talk about his experiences with Cloud Computing on EC2.

After all, once this great Philly data is out I'm going to need that elastic processing power....

Where the Agile Manifesto starts with “Individuals and Interactions” the Harvard Business Review kicks off Jugaad with “Thrift not Waste”.

All too often I’ve seen Agile work because a scarcity of resources (money, time or knowledge) pushed an otherwise waterfall loving group into giving Agile a shot. The tenants of Jugaad resonate with me as a more general philosophy about how to get things accomplished then Agile’s focus on “working software”.

Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value

Jugaad (quoted from HBR):

It feels like we are talking about the same thing. Get a team together and empower them to solve the necessary problem. Nowhere is there a concept of ‘throw money at the problem’ or ‘hire more consultants’. Plan for change and change plans in order to achieve success.

I’m on a barcamp high today. We could have had a conference with a big budget, focused our marketing on the demographic of web designers/developers, planned it from an executive committee and wrote a gant chart tracking the critical path from start to finish. It would have been a big show, but it would not have been barcamp and it would not have been awesome.

Software engineers learned that top down does not work. Indian’s entrepreneurs espousing that top down does not work.

Spend a few moments today to consider if you think top down, centralized control of food production is a good idea: http://foodfreedom.wordpress.com/2010/04/24/s-510-is-hissing-in-the-grass/

We were recently having a lunch conversation and talking about how to get involved in the local tech community. Kevin simply stated "Just show up".  It was a stunningly simple answer.

To people that have had the great experience of being involved in the Philly tech scene this seems obvious.  As a Gen 'X'er that moved around the east coast during the dotCom days let me say this is an unual and fantastic community.  Back in the day there was some feeling of elitism and you had to demonstrate some effort to be included in a 'community'.  Its true that a 'noob (great word, best contribution of the 'millenials' so far could show up at the local Linux install day and get some help setting up slackware on left over office equipment, but they were not taken seriously in the 'real' meetings.

When I moved in I had to throw down my triple homed T1 router built on freeBSD just to get a slice of pizza.

Things have absolutely changed.  I showed up at the 'mashable.com/Indy hall party' last night and the converstations were easily flowing.  I sat down at some random table and got into a CMS discussion contrasting my recent Alfresco for the portal action to UPenn's current e-learning on drupal issues.  We talked about Scala v Groovy and I even met the previous manager of one of my developers (Found he also takes credit for John's great work!).  I'm thinking the guy who recommend not using the front brake to stop my motorcycle was from a differnet crowd. (note:  saying that the 10% extra braking of the front wheel stop the bike is not worth the risk of fishtailing is wrong.  Bikes have 2 wheels and 2 brakes for a reason.   I'm not telling you what is right because some things should not be learned from a blog.  Take the MSF course, please. I don't have many readers here so I'd hate to lose one)

So in short if you want to be involved, just show up.

On a related professional note I have been reading an enjoying Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. It is a humorous take on the project management side of software development.  It uses the concept of 'design patterns' to discuss behavours (and solutions).  The one common one that I see professionally is the 'Movie Critic'.  This is the person that shows up 3 months after the project starts with an 'opinion'.  Sometimes you can't just say "where was this opinoin back when we needed it'.  Perhaps these people felt that there was a high barrier of entry to get into the project at an earlier phase?  We have internal blogs, wiki's and even do development co-located around big tables.  Everyone is welcome. People just need to know they are welcome.

So if there is something you care about please just get up and do it!

'Just Show Up'

(except riding a motorcycle, that can mess you up.  Get some in-person professional advice.  99% uptime is not good enough on a bike)

I talked a lot, learned a lot, drank a lot and made some friends in the process.

Each session exceeded my expectations in different ways.  My talk on the how we build and operate http://www.comcast.net was very well received and it was very telling to step up from the weeds and view this creation with my peers.  As much as we need to move forward sometimes we at CIM forget how far we have come.  Since this was an untelevised, ego and marketecture free event we openly discussed what we did right and wrong. Having this talk with people that live through this grind every day is very different then having it with people that learned the 'right way to build websites' from books or blogs.

"Don't hire legacy developers, kill legacy systems"

--My quote of the session

You guys really work hard, Comcast should hire more developers.

--Audience quote of the session

From there I went to a "Web Standards' talk given by someone that lived through it at AOL.  Given my challenges of getting standards adopted at Comcast this was also a great learning and sharing session. We discussed what needs to happen in our educational system and industry in order for Standards be become accepted as a core part of webdev and not a 'nice to have'.

Who would hire a web developer that does not follow standards?

--Audience quote of the session

After a quick lunch attempt at a local Indian place (service in 45 min: FAIL) we returned for a talk about innovation.  My intent of this session was a he said / she said comedy routine with Arpit where he would play the role of the frustrated developer and I'd be more of the pointy haired boss keeping our hapless developers trudging towards a deadline.  Interesting enough this session redefined the term "Innovation" for me as the talk went in a completely different direction.  By the definition of my peers we have been innovative. Much of our innovation has not been customer facing so it does not fit with the typical management concept of what they expect to see with regard to innovation.

A very interesting undercurrent was that most people innovate by padding their time or otherwise hiding this effort from their bosses.  I commented that I think this is disrespectful to the bosses and the responses again surprised me.  It turns out that most people feel that the top execs are very cluefull and 'get it' at many levels.  They also feel that the middle management just below them have no clue.  The other key factor in stifling innovation in large organizations is the inherent disrespect across disciplines. For some reason many people think that innovation has to come from their immediate team rather then the larger group.  (So for example the HTML devs have to innovate as opposed to the team consisting of HTML/IA/Design/Biz/QA etc..)

The other great take home was that the entire crowd was supportive and we all wanted each other to succeed. I never experienced such a positive vibe about Comcast in Philly and how much the tech community was behind us to succeed.  There is nothing in the way of CIM (Comcast Interactive Media).  I do think that we finally have that 'critical mass' of community here in Philly and it is time that the East Coast become known as a center of innovation.  There is some great talent in this region, from us corp developers to the fierce independents at Indy Hall

"We are not the Comcast you know and hate, we are the Comcast you don't know and love"

--Quote of the session

All this was less then half my day. Stay tuned for more!