Water Rocket

My son Max turned 4 yesterday. We had a rocket-themed birthday party for him so I found some instructions on the internet on how to make a water rocket. I'm not much of a handy man but this looked like an easy enough project. The results were somewhat disappointing for me, but luckily 4 year old boys are pretty easily impressed and it was a pretty big hit:
Launch I
Launch II

It looks like the seal at the mouth of the water bottle needed to be tighter and we were going a little overboard on the air pressure. The seal at the top was formed by heating up the PVC pipe with a candle until it became flexible, then pushing inward on both sides to create a bulge. The bulge I made was off to the side a little bit so I'm not surprised that caused a problem. I think if we could have figured out just the right amount of air pressure before it broke the seal we could have gotten a pretty decent launch. So I'm hoping to use it again in the near future to see if we can get better results. If we can't, it was easy enough to make that I'd like to try again, maybe when Max is a little older and can help build it.

Overall it was a fun experience and educational. It definitely made me want to find other projects to work on.

30 Days to Success 1.1

On Monday, Apple approved the new version of my iPhone app, 30 Days to Success. The new version doesn't contain anything too compelling:

• Added functionality to restore application state at launch.


• Updated application to only retrieve user Facebook info as necessary.


• Added nicer view for Facebook Wall of Fame page.


• Added functionality to share the application link with email contacts.


• Added a friendly reminder to provide a review for the application.


• Fixed some minor bugs.

I added the reminder to review the application using Appirater and integrated Facebook's Three20 library to make a much better view of the Wall of Fame. Adding state restoration was a bit of a pain but I figure if I'm going to charge for my app, I need to add little niceties like that.

I also updated how I retrieved user Facebook information. To post to the app's Facebook page, the user must "like" my Facebook app. Because the user might like/unlike the app, I need to make sure I have the latest info and prompt them accordingly if they try to post one of their successful trials to my app's page. Because it was easier on me, I was retrieving that information when the app started up. But that was a sub-optimal user experience as that information only is needed when posting to the app page. So that was a needed change as I was putting myself ahead of the user.

For my next update, I plan on adding functionality for users to suggest potential trials. I'm going to create a small set of web services on Google App engine that will allow users to submit a trial suggestion, email me a notification so I can review the suggestion and then return the list of suggestions to the app.

Javascript closures

A couple of days ago, there was a thread on Hacker News regarding Javascript closures. The thread referenced a question on Stack Overflow asking how best to explain closures. I'm not going to try and explain them here, but instead describe when the light bulb finally went off in my head regarding closures.

For one of my web app projects, I needed a small component to display the number of characters being typed into a text field (a la Twitter). Unfortunately, I didn't think to check for any existing jQuery plugins for such functionality as there are quite a few. Fortunately, I just rolled my own and in the process finally realized the power of closures.

My implementation turned out to be:

this.AddCharacterCounter = function(textField, counterField, characterLimit)
{
   var updateCounter = function()
   {
      // All the code here to count characters and set css styles
      // based on whether or not the limit had been reached.
   };

   var handleKeyEvent = function(event)
   {
      updateCounter(textField, counterField, characterLimit);
   };

   textField.keydown(handleKeyEvent);
   textField.keyup(handleKeyEvent);
   updateCounter();
}

Then for any field that I wanted to attach such a counter, I just had to do the following:

that.AddCharacterCounter($('#field1'), $('#field1Counter'), 300);
that.AddCharacterCounter($('#field2'), $('#field2Counter'), 150);
that.AddCharacterCounter($('#field3'), $('#field3Counter'), 30);

Project Management: UI

One thing I struggle with both as a developer and PM is UI. There are two particular examples for my history as a PM.

The first project was for an iPhone app where the client asked us to take their comps and make them more iPhone-friendly. Our designer took their concepts and made what I thought was a much cleaner, usable interface. Unfortunately the client didn't like the design and we went through several more iterations of updates, each side getting more and more frustrated as our ideas weren't converging. In the end it became obvious that the client always wanted their original concept/layout but were just looking for us to create nicer UI assets for the implementation.

The other project was a web application in which the client was extremely picky about the web site matching their comps pixel-for-pixel. The client did come up with a very nice design and provided us with very detailed comps so their pickiness wasn't completely unwarranted. As a PM and someone who doesn't easily pick up on UI design issues, I did not do a good job of vetting our implementation of the design before sending it on to the client. As a result a lot of time was wasted in back-and-forth communication to work out small UI mismatches.

So how could I have avoided these situations? In the first case I think it was mainly a matter of communication. I interpreted the client's instructions as giving us free reign to generate a completely different implementation of the client's concepts. In the future I will make a point to thoroughly discuss with the client what they are looking for when asking us to do UI work.

In the second case I think it's just becoming more aware of UI issues in general. It was obvious from the start that the client didn't want much/any deviation from their comps. But the web application was packed with functionality and as a developer, functionality is what I find interesting. In contrast, I can't just look at a label and tell what its font styles are and if they match the styles in a comp. In the future, I think I just need to consciously check for these type of issues, along with learning/practicing more design in my own side projects. I will also be more aware that a client that gives us detailed comps will probably be particular about how those comps are implemented.

One other step that I think would help in such a case is getting the general HTML/CSS layout in place and signed off by the client before beginning to implement any major functionality. Such a workflow would really make HTML/CSS changes easier rather than trying to force-fit changes later on in the project.

The folks at Herding Code recently had a very interesting podcast on situations like the second project I described here.

Project Management: Project History

One thing I wish I had done better on my current project is to keep track of decisions that were made throughout the project. Multiple requirements have been changed multiple times and have just become more complicated throughout the process. It would be nice if there was a one-stop place where I could go to review past changes/decisions and why they were made to better make sense of new change requests. Yes, most decisions can be retrieved by searching through email but I'd like something that I can just pull up and quickly glance over, digging down deeper if necessary.

So for future projects I'm planning on keeping a project journal to try and capture this information. I am going to focus on feature-level decisions as I can track task-level changes within our internal task system.

At first I was thinking that a wiki would be a good place to track this information, but I'm going to create a journal document within our internal collaboration system, FirstClass. Using a document will be pretty convenient since I can drag/drop emails into the document to create links back to the conversation threads where changes were discussed and approved. These links will then serve as a way for me to dig down deeper to revisit past changes and as a gentle reminder to clients of the change requests that were made during the project.

TO B.R. HAYDON, ESQ.

High is our calling, Friend!--Creative Art
(Whether the instrument of words she use,
Or pencil pregnant with ethereal hues),
Demands the service of a mind and heart,
Heroically fashioned--to infuse
Faith in the whispers of the lonely Muse,
While the whole world seems adverse to desert:
And, oh! when Nature sinks, as oft she may,
Through long-lived pressure of obscure distress,
Still to be strenuous for the bright reward,
And in the soul admit of no decay--
Brook no continuance of weak-mindedness:
Great is the glory, for the strife is hard!

William Wordsworth

Project Management: People

One of my favorite blogs is Rands In Repose. Rands is the only person I've ever read that makes project management sound both fun and challenging. He really seems to be able to get into the heads of people and understand what makes them tick. While reading his book Being Geek, I thought to myself that I would really enjoy the challenge of being a full-time project manager in the future (there's always time to write code in my off hours...just ask my wife ). But I don't think I'm at that point yet as I'm not ready to give up writing code during my day job.

One area of project management that Rands focuses on is managing people. At Art & Logic, I have the luxury of focusing most of my energies on the project. I'm not responsible for managing anyone's career path or filling out yearly evaluations. It's basically a matter of defining and doling out tasks. I do my best to try and match developers with tasks in which they have genuine interest, but that isn't too difficult given the unique types of projects we get.

One interesting aspect of project management at Art & Logic is that I'm always managing new people. Part of me enjoys the opportunity to work with new people. At the same time, it would be nice to gel with a consistent team of people and developer deeper relationships. But it really seems to be the nature of consulting where projects come and go much quicker and it's necessary to match the project with people having the appropriate skills.

But again, I'm thinking that it might be fun in the future to work for a product company and manage a team of developers on a commercial product. It would definitely be a new challenge to be responsible for a single product and a single team. I also think it would be fun to be more of a mentor and help people along their paths to become better developers.

Project Management: Time

Art & Logic bills on a time and materials basis. This is a good thing, but as a project manager I often struggle with the thought that every hour I spend on PM tasks is an hour I take away from developers to get the real work done. At the same time, an hour spent on PM tasks could prevent countless hours of wasted time later on in the project due to a miscommunication/misunderstand of requirements.

It's quite a balancing act to find that right level of involvement where you have all of the details that you need, while still squeezing out as many hours as possible for the developers. I like to think I've found that balance, though I tend to be a little more hands-off due to being a developer myself. I understand the negative impacts of interruptions and what it does to flow-state. So far this method has served me well and I think that's due to the following reasons:

• I work with a great group of developers that can take a task and complete it with minimal direction.


• I'm very detail-oriented, so even though I try to limit the hours I use as a PM, I have the complete picture of the project in front of me in my GTD system.


• A more "hands-off" approach fits with the JUST-SUFFICIENCY model stated in Art & Logic's development manifesto. An example of this in my PM style is to limit the project's tasklist to the features/tasks that are in the immediate future instead of populating the tasklist with the entire set of requirements at the beginning of the project. It's a given that many of those requirements will be changed/removed before the project comes to a close.

Another factor that comes into play is the type and size of the project. A small iPhone application does not demand the type of attention that a large web application does.

I'm constantly tweaking how I do things and am hopefully improving with each project. My ultimate goal is to continue improving the efficiency of my workflow as a PM, enabling me to get more information about projects in less time.

Next Few Posts

It's late so I'm going to cheat a little bit tonight and make a meta-post about my upcoming posts. When I started my job as a consultant at Art & Logic, I came in expecting to write code a majority of my working hours. After a couple of projects, it became clear that client/project management was also a pretty big part of the job, especially when working as a solo developer on a project.

Over the past year and a half, I've had the opportunity to manage teams of people on some pretty large projects. Before I started at Art and Logic, had you told me I'd be a project manager, I would have asked you to put me out of my misery now. My thoughts on project management/managers were too similar to Dilbert cartoons.

However, I've really enjoyed learning project management and I feel that I'm getting better at it each project. My next couple of posts will talk about some of the experiences I've had and lessons learned while starting out in this new role.

Beginner JavaScript Trick

So this trick is probably old-hat for any experienced JavaScript programmer, but the problem it solves tripped me up when I first started using JavaScript in depth. I was maintaining code written by another developer and at the beginning of every JavaScript module he wrote he would always have the following line:

var that = this;


I didn't really understand the point of it at the time until I later ran into a frustrating bug where this wasn't pointing to the (top-level) object I thought it should. Sure enough, it was because I was referring to this within an event handler and this was pointing to the target of the event rather than the top-level object. The light bulb went off in my head. So whenever you want to refer to your top-level object, you can just reference that and use this everywhere else. This article provides a good explanation of the issue.

Sometime later, I was watching Douglas Crockford's JavaScript lectures on Yahoo and saw that he uses the same technique. Unfortunately, those videos are no longer available on Yahoo.

Software project ideas

While testing my new iPhone app, I completed a 7-day trial to brainstorm three new mobile app ideas per day. When Apple says "there's an app for that" they're not kidding. Coming up with an original idea is pretty close to impossible. I wasn't limiting myself to original ideas and even searched the the app store to see if there were any ideas I could improve on. But any simple ideas have likely been done.

For example, on the weekend of my trial, Max and I camped out at my in-laws and we toasted marshmallows. "Aha!" I thought. That would be a good gimmicky app (I was going for quantity here, not quality). Searching for marshmallow on the app store didn't turn up anything. But the next day it hit me I didn't search for s'mores and sure enough...there's an app for that.

I did think of a couple of apps that don't seem to be in the store but they would require nice graphics and I'm not looking to do anything where I'd have to hire someone to do that work.

By far the ideas I thought were best were apps for existing companies/entities to supplement their current offerings. I have several ideas now for apps for local businesses/friends . When I get some free time I'm definitely planning on approaching some people to see if they're interested.

30 Days to Success

This week Apple approved my iPhone app 30 Days to Success, which is an application based on Steve Pavlina's article of the same name.

I've had the idea for this app for several years now and actually developed a prototype 2 years ago. I emailed Steve to see if he would be interested in the app but he declined. So I dropped the idea not wanting to infringe on his copyrights.

But late last year Steve released all copyrights to his online content so I decided to start the project back up.

Back in the prototype phase, I had created my own hideous calendar UI. After stopping work on the project, I ran across the Kal library when doing some estimates at my day job and and knew that was something I would have to integrate. So with a better looking UI and some updates to integrate Facebook and Twitter, I thought I had something that was worthy of release. There are a couple of things I'm still not happy with but I will fix them over time.

I'm not expecting too much income from the app although I'm hoping to make a little bit of passive income off of it in the long run. I think I have a couple of things going for me:
- I can take advantage of Steve Pavlina's already large audience.
- Integration of Facebook and Twitter will put the app in front of a lot more eyes.
- I'm planning some other social features that should encourage current users to get others involved with the app.

I had one sale the first day and two sales the second day. Assuming this exponential growth rate continues, I'll be at a million sales in no time :)

Day 1 of 30

In honor of the release of my new iPhone app to the iTunes store, I am going to try and complete a 30 day trial to write something here every day.

I've queued up about 10 topics I'd like to write about so I should be good to go for at least the first week and a half.

And with that, Day 1 is a success ;)