ShareThis1 |
Lead the design and implementation of the next set of Edison features (see below). Since our wonderful Andy is busy, I'll need to find a Ruby on Rails person to augment the fabulous Edison team (Liza and Graham). Features:
|
2 |
When the new features are up and running! |
3 |
My (ambitious) goal is to finish by mid May. |
4 |
Learn about leading a team and finding a contractor. Be open to surprises. *Really* celebrate when completed, because these are the critical features we think Edison needs before we can create a broader community. |
Create an Experiment
Matthew Cornell
- Member Since
- 07/02/09
- About Lover of experimentation and leader of Think, Try, Learn, the scientific method for discovering happiness. Creator of Edison, the Think, Try, Learn experimenter's workbook. http://edison.thinktrylearn.com/ http://www.thinktrylearn.com/ http://www.matthewcornell.org/
- Web http://www.matthewcornell.org/
- Experiments 98
- Observations 1262
Comments & Observations
Matthew Cornell Started looking for the RoR person, with local outreach first. This last week I posted messages to:
o Five Colleges LinkedIn group
o Western MA LinkedIn group
o hidden-tech
o techies in my personal LinkedIn network
o western ma craigslist
I'm curious what responses I'll get. So far I've had three.
Apr 24, 2010
Matthew Cornell Whew! Did a comprehensive review of all features, issues, and discussions to date, created updated and annotated screen shots, and listed all feature details. Uploaded all these to the development team site, and waiting for comments! It helps to say that I'm new at this, and ask for help making it understandable and relatively easy for my busy volunteers to comment and answer questions. It's a bigger project than I thought, but extremely cool.
Apr 24, 2010
Matthew Cornell Getting local Heroku development environment installed on my Mac. I forgot how complicated programming tools are. At least I remember how to type terminal commands!
Apr 24, 2010
Matthew Cornell Learned some of Liza's design process today, and it's about 100% opposite to what I'd planned. Surprise! In a nutshell:
o design enough to get sense of time required to implement
o use personal network to find candidate contractors
o goal: form longer-term relationship with them
o talk with candidates to get a feel, describe the scope of the project - about 15 hours - and get a rough sense of interest and $
o decide, then get them them on-board
o finalize design and spec w/team
o go!
Apr 25, 2010
Matthew Cornell A quick update: Of the 5 direct references from my network for Ruby On Rails programmers, 4 have not panned out. Two surprises there - number I got was lower than expected, and that they were busy. Interesting! However, constraints are useful because they simplify decisions and direction. Of course I could choose to push back against the resistance, but in this case the person remaining has a great reputation and will be available next week. So I'll put off the search until he and I speak then. It can be fun to see what the environment is telling us.
May 03, 2010
Matthew Cornell Great news! We have Jake Mitchell on board to program v1.2. Jake will be super. Plus, he's famous for the "Avoid owning a car" experiment - http://edison.thinktrylearn.com/experiments/show/148 . Our timeline is to get it done in three short weeks. Go Edison!
May 17, 2010
Matthew Cornell OMG! "View all __ comments" is live! Click it and notice it expands in place. Jake rocks! Question: Should the page scroll to the last comment? I'll check FB.
Jun 04, 2010
Brock Tice I'd prefer it showed all of all of the comments. Right now it's like: Read. Decide to see more comments, so click "View all _ comments". Realize that many comments are still truncated. Click "see experiment". Scroll to comment.
Jun 04, 2010
Matthew Cornell That's helpful, Brock. We're following the Facebook model, which I think differentiates between two kinds of comment reading, which doesn't seem relevant in your experience. Already this 1.2 experiment is yielding data - from you. I'll put it in the system for follow up after 1.2 is done. I don't think it'll be too hard to integrate the two, i.e., to expand everything. My worry is that it might be slow. I don't know how Jake implemented it, but if it's all being loaded with the page, it would be fast (javascript). Otherwise, pinging the server might slow it down.
Jun 07, 2010
Brock Tice Might be able to compromise the way Facebook does by hiding the comments in the middle, and just showing the (full) first few and last few comments. Usually it's only the last few comments I'm looking at anyway, but you know that's just me. :)
Jun 09, 2010
Matthew Cornell Liza and I scoped out how we now want the 1.2 version to work, much like FB in function and layout. I'm checking with Jake to make sure it's not too crazy to implement.
Jun 10, 2010
Matthew Cornell Jake is moving along. The Facebook Connect feature will take some experimenting, but he's confident the others should be available shortly.
On a related note: I've ordered a couple of dozen TTL t-shirts as part of a post-1.2 promotional contest to attract users. Ideas welcome!
Jun 20, 2010
Matthew Cornell Some important surprises and lessons learned during this process. I'm hopeful that we can get all features but the Facebook Connect released before next week.
Jul 08, 2010
Matthew Cornell OK, I'm marking this completed, though the Facebook Connect feature will have to be added separately. I'll arrange that in the next week.
This experiment brings up the question of what's an experiment vs. what's a project. My first thought is that Edison is itself an experiment, but this release was not. But after further thought, this *was* an experiment due to its being the first time I've led a software development project.
Lessons:
o Be active in staying on top of the project, including being in contact with the developer every week at a minimum. If things are going to be delayed, root that out early then replan. (Fail fast, fail noisy.)
o Be clear and continue to be clear on how the developer is spending his time. I had a miscommuniication that was a costly use of his time on a low priority feature.
o It's very important to stay flexible re: feature specs. You will discover things about features that need changing due to details coming apparent during the implementation. It's impossible to anticipate everything. Having a developer who understands that, rather than a stickler, is crucial.
o Stay on top of the inter-developer communication. I had assumed my developer and my UI coder would pretty much work things out on their own, but I should have communicated with them separately, and frequently, to see if there were gaps or blockages. In this case the developer spent time on something the UI person should have been working on (and could have done faster and cleaner).
o People sometimes drop the ball, become unresponsive, and have unforseen events get in the way of the initial plans. Again, detect early and replan accordingly.
Overall, I'm really happy with the finished product - it's polished, functional, and snappy. The team's flexibility and creativity were top notch, and remind me how wonderful it is to be working with excellent people. Given the feature set, I would have been much happier if it was done in two weeks instead of eight, but that was not possible this time around (first time lessons, and unforseen circumstances). *Great* experiment.
Jul 20, 2010