Now THIS is Marketing

Not only to the Wheeling Nailers go after WVU fan, with Shred Rodriguez night...but they offer discounts to OSU fan as well for "mutual distaste of Michigan".

Crew Blog

In the web stone ages, I worked on CrewFan.com The site is long since dead, but it was essentially a blog on the crew.

Now, much like the Puckrakers blog on the Jackets, the Dispatch has ponied up for Crew beat writer Shawn Mitchell.

Covering the Crew has been up since the MLS Superdraft. So far, it's been outstanding. Given the amount of inches the Crew gets in the print editions, this has been a very welcome addition. Where else are you going to get the quick scoop on the pursuit of Maciej Zurawski, with a purely Columbus perspective?

Keep it up Shawn.

In House Software vs. Software Companies (BoIB)

Originally posted on December 4, 2007 on the internal blog:

Joel Splotzy has two new posts where he provides the transcript of a speech he gave at Yale. The basic premise is his career and how he got to be where he is.

It's quite interesting, and quite frightening. I've seen some of the places he's talked about when he goes off on the "80%" of programming jobs that deal with in house software.

That’s the second reason these jobs suck: as soon as your program gets good enough, you have to stop working on it. Once the core functionality is there, the main problem is solved, there is absolutely no return-on-investment, no business reason to make the software any better. So all of these in house programs look like a dog’s breakfast: because it’s just not worth a penny to make them look nice. Forget any pride in workmanship or craftsmanship you learned in CS323. You’re going to churn out embarrassing junk, and then, you’re going to rush off to patch up last year’s embarrassing junk which is starting to break down because it wasn’t done right in the first place, twenty-seven years of that and you get a gold watch. Oh, and they don’t give gold watches any more. 27 years and you get carpal tunnel syndrome. Now, at a product company, for example, if you’re a software developer working on a software product or even an online product like Google or Facebook, the better you make the product, the better it sells. The key point about in-house development is that once it’s “good enough,” you stop. When you’re working on products, you can keep refining and polishing and refactoring and improving, and if you work for Facebook, you can spend a whole month optimizing the Ajax name-choosing gizmo so that it’s really fast and really cool, and all that effort is worthwhile because it makes your product better than the competition. So, the number two reason product work is better than in-house work is that you get to make beautiful things.

One of the interesting things about this segment is the assumption that working on Products actually means that you're going to implement something that makes it better for your user. Sometimes, you make it better for your backend, which is far less glamorous than working on the frontend. Sometimes cool features get cut because, your customers aren't ready for it. I can think of several products which took several years to incorporate cool javascript gizmos, let alone Ajax gizmos because our customers were not ready for it. In essence, a segment of the customer base doesn't want the product they integrate into their online presence to look better than the rest of their online persona. There are customers who I've worked with who use older technology in 10% of their application simply because they aren't ready to fund the upgrade to the newer stuff.

It's unfortunately just not that simple in every instance.

Joel also comments on management styles when recalling his time at Juno:

Eventually, though, I started to discover that the management philosophy at Juno was old fashioned. The assumption there was that managers exist to tell people what to do. This is quite upside-down from the way management worked in typical west-coast high tech companies. What I was used to from the west coast was an attitude that management is just an annoying, mundane chore someone has to do so that the smart people can get their work done. Think of an academic department at a university, where being the chairperson of the department is actually something of a burden that nobody really wants to do; they’d much rather be doing research. That’s the Silicon Valley style of management. Managers exist to get furniture out of the way so the real talent can do brilliant work.

My first question here is, who decides if the investment is worth it? I suppose if you're a startup with a ton of angel funding, it doesn't matter if it's worth it to upgrade gizmo X. But if you're a software services company, it does matter. If contracts are written in ways where it really doesn't matter if you create gizmo X because no one's going to pay to upgrade to it, then you probably aren't going to do it. Someone has to manage that. It's not a chore in this case. In this case it's paramount to the survival of the company that allows you to create cool gizmos. Someone has to understand the customer and what brings in the coin so that the correct gizmo X Y or Z can be created.

Joel is a bit simplistic in his view because he makes the assumption that you're always going to do what's cool working for a software company. You will do cool stuff quite often, but in many cases, you aren't. You're going to do what provides the best return on investment for our customers. It's not always glamorous, but it's what keeps you employed. You need management because you need to sell product. Yes, managers should help to get furniture out of the way, but they also need to be smart enough to step in when the team is floundering and not making the decisions needed to be successful.

I do agree with Joel on one thing, however. In house software is not as fun as working on software services. Software services gets you working with internal and external clients. It's challenging and keeps a set of social business skills nimble that you might otherwise neglect.

Book Review - Managing Humans (BoIB)

Originally posted on December 3, 2007 on the internal blog:

About three weeks ago, I got an email from the Columbus Metropolitan Library that "Managing Humans" was available. It's taken me a while due to other commitments to finish it and this review, but here goes.

Managing Humans is the first book by Michael Lopp, otherwise known as Rands from Rands in Repose. It is an updated and edited collection of essays from the Rands in Repose blog that focuses on management, specifically managing software engineers in software companies. Lopp's resume is quite extensive, taking him around Silicon Valley and back through Borland, Netscape, Apple, Symantec and the failed startup. Through the diversity of these stops, he's come up with a set of tales about management and various personalities you encounter in the workforce.

If you've read Rands in Repose, you know that it's very snarky and pointed in its commentary. Managing Humans tones these two items down, which allows the book to be a bit more accessable to the masses. It's very funny and "too true" in many of its passages. Lopp gives many of his characters names which are catchy. You will probably find yourself saying things like "I know a Fez and his name is....", or "my manager is sooooo Organic".

The catchiness of the book allows it to disseminate quality information in a consise 200 pages and appeals to managers and their employees at the same time. For managers, the importance he places on the one-on-one is and communication is very compelling. While for the staff, the importance of understanding who your manager is and how he thinks is a great start on figuring out how to "manage" your manager to help hims succeed and make sure he knows that you are doing it.

When you do get the book, be sure to read through the glossary which contains many terms which you should probably know if you're in software engineering. My personal favorites:

• Synergy - A word used in close proximity to Leverage
• Leverage - A word used in close proximity to Synergy
  

If you don't find that funny, then, maybe this book isn't for you. If you do, go pick it up.

I highly recommend this book for ease of reading, entertainment and insight. It's worth a purchase and a place on your bookshelf for quick reference of how to manage people to help them and you succeed.

PDF "Trouble"

I like Jeff Atwood's Coding Horror blog. I use it as fodder for many posts at my internal work blog. It covers a lot of "looking forward" topics for my group, but it doesn't hit home as much as it could. Some of those topics are so far out that my coworkers just aren't thinking about these things yet.

That changed today.

Jeff's post on PDFs is directly relevant to things that I do on a daily (or monthly) basis. In it, he argues against PDF and for HTML, which 99% of the time is fine. The user experience is better with HTML, it can do neat things by interfacing with the browser.

However, it doesn't allow the user to save their content. PDF does. Why is this important? Because you need to save a legal document.

An aside, my work currently consists of producing electronic statements for large companies. Your monthly cable bill, your wireless bill, your credit card bill...you name it...online. I have produced many HTML based statements, which are great. They interface with the end user, can allow them to sort transactions in some cases, or download CSV files to import into a spreadsheet. So why is it, that I argue against Jeff and for PDF? Because you can save PDF and get a file that looks and feels like that paper document I get in the mail.

Look and feel is important for large companies. They have spent loads of cash on print document authoring software. They spent even more cash on print vendor contracts or large print shops. It is important that the document they produce for paper looks the same or very similar then the one on the web. It reduces customer care costs if they are the same. PDF allows for that. You can do it with HTML, and some forward looking companies and utility startups are doing so.

I believe Jeff is simply ignorant of some of the uses for PDF, and probably doesn't know about the world I interface with.. But read the comments and you see a lot of users who just don't understand the advantages of PDF when it comes to statements. They overestimate the client and their legal team, as well as the end user.

As companies try to get more "green", they will try to reduce paper costs which means turning paper off for customers. As this occurs, HTML (well, actually the browsers) will have to come up with a better way to save a statement. Obviously IE can package a statement in an mht file. But Firefox, Opera and Safari can't. And we all know the holy wars that are unleashed when you limit your audience to one browser.

West By "Gosh" Virginia?

Has our society become so scared that we take a simple phrase and replace God with Gosh?

Who are we? Goofy?

That's exactly what the play by play guy on Fox said when he repeated the phrase my father uttered so many times over the years. Of course the Fox announcer probably just heard it for the first time when interim coach Stewart bellowed it at 2:20 of this clip.

Just another example of someone being too PC. Either the announcer or his producers were scared to say "God".

Wow.