Big Dave’s Blog

If you are a software developer or manager of a software development team, how many times have you heard something like “This is cool, we should do it!”? Whenever I hear that, I get nervous. Don’t get me wrong, cool stuff is, well, cool, but that doesn’t mean it is valuable to the customer. Remember the days of the big desktop applications throwing every feature possible into their applications? You still see it to some extent, but not to the level of Lotus vs. Microsoft in the late 80s and early 90s. When I was at Lotus, we had features that were specifically in there because they were cool and demoed well. Very few people would actually use them, but they were cool damn it! At that time, you could almost justify it, but I never bought all the wasted resources.

With small companies and limited budgets, you have to concentrate on valuable. Customers demand it, and my budget can’t afford to build anything that isn’t valuable to the customer. Normally, I hate the term “good enough,” but it applies well to software. Software should be good enough, and no better. Anything else is wasting resources. I’m certainly not the first person to say this, but it works for me.

Now, there are are products and features that are both cool and functional - the iPod comes to mind. If you can find that, then you really win, but no matter what it is, it must be functional above all else.

So, next time you think up some cool feature, take a step back and look at it from the customer perspective. Does my customer really need that fancy Ajax drag & drop tool? Is this going to make my customer’s life easier? If the answer is no, then forget it and move on.

At one point in my career, I had a sign on my desk that read: “No. What part of this don’t you understand?” It was only half joking, but it got the point across that features and changes needed customer value before they got into the project. In the end, I will take functional over cool any day. Cool wears off, but functional usually keeps being functional.

I’ve been a little busy for the last few months. As I hinted at a couple of times, I’ve been working on a new venture. Well, that venture is starting to get more public. My partner and I have been working on Inquisix. Inquisix is a site designed for sales people to help them meet better prospects. I’m having a blast, and it’s great to be able to talk about things more.

Anyway, the interesting technical item that came up is related to our blog. At my last startup, I migrated my team to Ruby from Java, and I haven’t looked back. That made Ruby on Rails an easy choice as a development platform for Inquisix. Of course, we also wanted a blog. There are Ruby alternatives for blogging. Mephisto is probably the best example, but I am more familiar with Wordpress. While it would be great to have a Ruby blog, it’s hard to ignore Wordpress for blogging, and I’m not a big enough Ruby zealot to require that everything must be Ruby. Therefore, I decided on Wordpress.

However, there is one problem. I wanted my blog’s url to be http://inquisix.com/blog. How do I convince PHP and Rails to co-exist on the same server? After a little searching, I found a great blog post by Ilya Grigorik - Integrating Wordpress and Rails. At first, it worked great, but things failed when I tried to change my settings to use permalinks based on dates. Once I did this, only pages with an existing physical file worked.

This is what Ilya proposed for a local installation of Wordpress:

# Check for maintenance file and redirect all requests
RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /system/maintenance.html [L

# Let apache handle the PHP files - all requests that get past this rule
# are routed to the mongrel cluster (aka Rails
#  - wordpress installation assumeed to be in 'public/wordpress'
#  - Options: NC - case insensitive
#  -          QSA - query string append
#  -          L - last rule, aka stop here if rewriterule condition is matched
RewriteRule ^/blog/?(.*)$ %{DOCUMENT_ROOT}/wordpress/$1 [NC,QSA,L]

# Redirect all non-static requests to cluster
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

This is what I ended up with:

# Check for maintenance file and redirect all requests
RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /system/maintenance.html [L]

# Let apache handle the PHP files
RewriteCond /opt/apps%{REQUEST_FILENAME} !-f
RewriteCond /opt/apps%{REQUEST_FILENAME} !-d
RewriteRule ^/blog/?.*$ /opt/apps/blog/index.php [NC,QSA,L]
RewriteRule ^/blog/?(.*)$ /opt/apps/blog/$1 [NC,QSA,L]

# Rewrite rule for Rails static assets
RewriteRule “^/(images|stylesheets|javascripts)/?(.*)” “$0″ [NC,QSA,L]

# Rewrite index to check for static
RewriteRule ^/$ /index.html [QSA]

# Rewrite to check for Rails cached page
RewriteRule ^([^.]+)$ $1.html [QSA]

# Redirect all non-static requests to cluster
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

The problem with Ilya’s is that it rewrites everything to a physical file, but when Wordpress is setup to use slugs, this will fail because the physical file doesn’t exist. If the file doesn’t exist, you need to rewrite the url to index.php.

For grins, I also added a line to let Apache handle Rails cached files, images, stylesheets, and javascripts because Mongrel is not that great at delivering static assets.

I’m still a little new to Apache configs, so if someone has a better way to handle this, I’m all ears.

Windbelt - Third World Power - Wind Generator - Video - Breakthrough Awards - Popular Mechanic

I love it when people take something simple and make it useful.  Turning this macro will be a trick, but it is a neat concept regardless.

Put this down as another one of those “Why didn’t anyone think of this sooner?”

Why does it seem so hard to manage engineers, especially software engineers?  In my years, I’ve seen a lot of unproductive situations.  I’ve worked for and with some amazing people.  I’ve also had the pleasure and privilege of managing some of the finest engineers.  In general, I found the secret to managing a development team comes down to a few simple rules.

1. What are we working toward?  Note, this is not an individual goal.  This is the team goal.
2. What are the rules or parameters?   Is there a necessary platform or set of design patterns.  You need some rules, but don’t go overboard and be so restrictive that it stifles creativity.
3. GET OUT OF THE WAY!  This is the most important one.  In theory, you hired some smart, creative people.  Let them do what you hired them for.

I came up with these rules when I thought about what made me the most productive as an engineer.  It was always when I knew what to build, the restrictions, and was given the freedom to solve the problem.  This is probably why the Agile Development process feels so natural to me.  To have user stories that describe the desired result without specifying exactly how to do it lets me solve the problem far better.

Another thing that doesn’t hurt is to get your hands dirty once in a while.  No matter what level I am at, I always make it a point to understand as many details as possible, and often I jump in to help with coding.