RE: Tips for a PM

Alex wrote a post a few days ago about his experience as a product manager, and what he thinks is important for someone in that position. First, I found it really interesting to read as someone who has worked on the other side of that relationship (the one between a PM and a developer that is — I was the developer). I also think that what he said is spot on, at least in principle, so I wanted to start by reiterating the best part:

At one point I had all opinions, feedback, and data in my mind, and the presence of those things naturally affected the way I see this product. Even though I may not have incorporated certain opinions in my list of features, I at least incorporated those opinions in my decisions.

This is probably the most important attribute a PM can have (really anyone in a similar power position), because that’s their job! To often, I worked for/under/with people who thought that if they pleased the most people they’d be making the right decision. It’s important to realize that stakeholders usually have very subjective opinions. When I was developing PPI for MIFOS, there was a debate about whether to have the index algorithm be hard-coded or configurable by the client. I wanted it to be configurable because that would have meant I’d get to write a parser (which would be sweet), the lead developer wanted it hard-coded because it would be less work (and he needed me for fixing bugs and other fun stuff), and our Director wanted it in the DB because it would make upgrades easier. All of these are valid arguments (except mine), and my PM had to make a call. In the end, the decision wasn’t about making me, the lead, or our director happy, but about choosing the best course of action for the product (which is what she did in my opinion – hard-coded). I may not have gotten to write my parser (I did for school this autumn though and it was way harder than I expected), but I think the product is better, which is what I really care about in the big picture.

There are some finer points where I am going to try and supplement (read: mildly disagree with) Alex’s post.

He talks about positive motivation/energy, but specifically about taking your team out to lunch, happy hour etc’. Again, I think that in principle he’s spot on. In particular that in general I think it’s important to be friends with your co-workers – regardless of hierarchy. When I enjoy being around someone, I can have a laugh with them, I care about their general happiness – their goals become my goals, so it really serves to motivate me if I’m working on their project.
However, I can afford lunch. This may be less of a general philosophy than I might hope, but I really don’t want to be bought by my boss. I think the most important thing that Alex is trying to convey is how productive breaking down walls can be. Money creates walls, especially if you’re a superior. I do however think that going out to lunch, drink, ski, whatever… is a wonderful way of creating a sense of camaraderie. I also think that what made me feel most at home with my co-workers this summer is that we didn’t nickel and dime each other. If someone was short for lunch, or forgot their wallet, someone else would always spot them, and just expect that eventually it would come around.

Alex also mentions taking the blame when it’s otherwise not clear who’s fault it is. I’m sort of torn about this. All in all, the intention is good, but it feels wrong to me, as a developer. If I fuck up, I want someone to call me out on it. Even more importantly, I don’t want it hidden because I don’t myself, or others, to feel like it doesn’t matter if they mess up (I not suggesting that it’s not understandable to make mistakes, just that it shouldn’t be encouraged). On the other hand, I’ve heard horror stories from a certain software giant that sells expensive, buggy products (hint hint… MSFT), about managers et al who are really good at figuring out what everyone else is doing wrong and making sure their hands are clean, but otherwise dead weight.
So I don’t know.

Finally I’d like to add one more important way to motivate people. In Zionist-Socialist (in BC – long story) summer camp they called it, being a “Doogma” – which means an example in Hebrew. As cliche as it is, I think it’s super important. A manager (really anyone who’s working on something that’s important to them), should work as hard as, if not harder than everybody else. I think it sends a message that you’re not just clocking hours – that the project is really something you’re passionate about. That’s a really powerful thing, and it’s contagious!

Better Web Application Development

I originally posted a comment on Alex Loddengaard’s blog post titled Software Engineering a Startup. In turn, that inspired me to (finally) post on my own blog, which has existed untouched for eons.

The video is by a guy named Sean Kelly. It’s long so if you don’t watch it I won’t be offended… He talks about what constituents of a good framework for web application development, comparing and contrasting some specific web frameworks – J2EE, RoR, Zope, TurboGears and Django. Most importantly, Sean argues that fast initial deployment and rapid-turnaround are the most important factors in choosing a framework.

For the past 7 months I’ve been working on MIFOS for the Grameen Foundation – banking software geared at MFIs. MIFOS is built with J2EE, while RidePooler – a project I’m working on with my friend Courty – is built with Ruby on Rails. The difference, for me, in developing these two applications has been immense, in large part due to the frameworks used.

First observation: Developing with rails is much faster
A first draft of RidePooler was up and running about three days after the idea was conceived. This is important because it allowed us to consider what features were really great, and which ones were only great in our heads. It also allowed me (the sole developer) to do a practice run of the development. That’s something that is theoretically possible with J2EE, but highly impractical. The overhead to design the packages, do XML sit-ups, configure the server etc’ just takes to long. Not to mention writing the business logic, the hibernate configuration files, and the SQL schema is not straight forward at all. At MIFOS we’ve been using the same core code for almost two-years, even though everyone agrees better code design would save hours a week of debugging. Designing software should be like playing with legos – every now and again you just smash everything and start from scratch. Quick development means this isn’t as scary a thought.

Second observation: RHTML rocks the house! JSP rocks absolutely nothing…
The first reason for this is rails uses layouts in addition to includes to reduce redundancy whereas JSP uses only includes. This makes changing the overall look and feel of the application a much less flexible process. With RidePooler this is an issue right now because we’re updating the design. Because I used layouts for all of the views, updating the design takes very little time. At MIFOS, the design hasn’t changed since the first conception, in part because it’s neigh impossible at this point. I know the code pretty much inside out, but I still haven’t figured out which jsp includes do what. Moreover, there are literally hundreds of pages in MIFOS. Adding a couple includes with some nice new buttons (or something) would probably take a full day’s work – that’s wasted developer time.

Third Observation: Ruby is interpreted and Java is compiled
Duh… It’s not that I’m against compiling. Compilers are wonderful – they allow us to build interpreters! But really this is not a silly preference. Testing a compiled java web-application means re-compiling it, copying the build directory to the deployment directory, and restarting the server. Ecplise et al., are nice enough to do the compiling and copying iteratively so that doesn’t take as long, but even those 30 seconds are an eternity when all you want to do is see if you’ve successfully changed some output from first name to full name. Moreover, restarting the server can be cumbersome. MIFOS has thousands of class files and hundreds of configuration files, all have to be loaded by the application server. When there are no errors, that takes about 2 minutes.
Since Ruby is interpreted (unless I change a configuration file) once I’ve made a change it’s immediately available for viewing (you don’t even have to log out on authenticated applications). This makes for more engaged developers (less down time staring at the console) which – in my opinion – spurs creativity and perfectionism.

While I haven’t had much experience with python, I gather the web frameworks that utilize it are similar in character to Rails. These frameworks provide a platform for adapting quickly, and focusing on creative development – rather than mundane programming and infrastructure development. In the end, I think it is this property that will allow developers to build cleaner, easier-to-use, and more robust applications.