Bogeymin

I'm proud to announce the commencement of a new project called "Bogeymin" -- a command suite tool for managing Web servers and related services such as DNS and email.

Features include:

• Linux-based.
• Total control from the command line and complex automation for consistent maintenance and administration.
• Utilizes existing security technologies to safely permit access to level 1 support, level 2 technicians, and full administrators.
• Unique website organization system.

The project is scheduled for completion in October. Visit the official site to for the latest info and sign up to be notified when it's released.

The Shoe is On the Other Foot

I am a pretty good guesser and empathizer. I also have a good imagination. This helps me build Web sites and applications that are useful, thoughtful, and helpful to clients. Most of the time, anyway. It also helps me understand the client's perspective and win more jobs.

But after deciding to outsource the Objective-C portion of our iPhone application, I am now "the client". And the experience has been helpful in understanding even more of the client's perspective.

Timing and Silence

My chief complaint -- if it can be called that -- is getting the job done on time (which we have not) and hearing from the developer on progress (which was good at first but lately has been sporadic). Most of us (developers) are well aware that communication can be an issue, but this experience has really driven home to me the necessity of prompt communication.

• Say something, anything. Never let a message go unanswered, eve if it's just to say "message received". We often feel pressured to have news or progress before responding, but this takes time. Instead, let the customer know you're still there.
• Be up-front about delays. Let the customer know as soon as possible if there's going to be a delay.
• Be open about the current schedule for incoming change requests.

Silence leads to frustration -- don't frustrate your clients.

As a result, I have a new goal for communication with my own clients.

My First Experience with "Offshore" Outsourcing

I have scads of experience both building and managing software projects. I've also worked with a lot of people; full-time employees as well as contractors. My first experience with outsourcing a project went to India where I could leverage the exchange rates to purchase more hours for my dollars. I put together a fairly extensive project plan from which everyone could work.

After having review the source code and tested the application, I know the developer is competent. However, there are several things I will do differently next time.

1. My application needed a Web service. I was providing this service, but I wanted to let the developer have some leeway here -- the developer would know best as to what would be needed, right? This was bad. I should have defined the Web service before hand -- method names, parameter names, design by contract, etc.

2. Design. I am no designer. The developer did the design work. The graphic design didn't turn out bad but it wasn't what I wanted. The problem is, I didn't come up with a design concept until the work was well underway. I couldn't criticize a design that was otherwise okay because I was too unimaginative to come up with something on my own in the first place.

3. Layout, labels, and process flow were all left to the developer. Again, this didn't turn out that bad, but it could have been much better in terms of UI. I should have had my own screenshots in advance with flow-charts indicating how the user experience should be implemented.

There were of course times when the language barrier was a problem, but it was never a significant problem, especially via email. Planning -- even more than I had done -- would have saved a lot of time and produced a better product.

It's a Dirty Hack, But Someone Has to Do It

I had finished a fairly complicated application -- to the client's specification -- that featured a complex system for selecting advertisers for various types of announcements. Although the money was paid, the project lay dormant for many months until the client started selling the ad spots.

Unfortunately, the person selling the spots had been left in the dark on how the system was built and sold the ads in a way that was completely contrary to the current tools -- control panel, automation, and front-end were now incompatible.

I looked at every way possible to make it work within the capabilities of the application but there was no reconciling the way the product was sold and the way the product was built.

To make matters worse, the deadline for the "new" way of doing things was two weeks and I had already had a full plate. I sensed stupid hours in my future, but promised the client I would come up with something.

The more I got in to the code, the more I realized that it was worse than I anticipated. I tried several approaches, but everything was backward in terms of implementation and data that was previously needed in one place was now needed somewhere else -- some where the scope was completely wrong.

I really only had a weekend to work out a solution and the "real" way of doing it would probably take a week's worth of work.

Sometimes you just have to hack something in place. In this case, I bypassed all of the dynamic stuff and just hacked in the raw data for the specific advertiser. Yes, lots of really complicated and fascinating code was essentially discarded for a plain text band-aide that will have to be fixed some day. It wasn't pretty but it was simpler, and more importantly it got the job done quicker.

Sometimes the greatest difficulty in this situation is getting over the fact that you are hacking otherwise excellent code into pieces.

This brings me to yet another truth in programming:

It's a Dirty Hack, But Someone Has to Do It.

You are the best candidate to hack on your own code and when the rubber hits the road, the reality is you just have to do it.

But what can you do to minimize the damage?

1. Leave comments for yourself (or the next guy) wherever you need to change the code.
2. Use @hack or some similar marker so you can easily find the changes and comments.
3. Go back and fix it on a rainy day.

Lemonade Web Site Hosting

I've been managing servers off and on since 1998 and have been working with Web-related servers (DNS, FTP, HTTP, POP, SMTP) since about 2001. And starting around 2004 for, I took over the management of a small hosting company with about 1500 to 2000 websites.

It has always been frustrating to me when customers balk at a decent price for hosting. Everyone tends to gravitate toward the cheapest of any product, but having used various hosting services as well as operated my own, I understand better than most that real hosting costs real money.

What is "real" hosting? And why does it cost money?

• Hosting occurs on servers that cost money.
• Servers are located in a building that costs money.
• Connecting the servers to the Internet costs money.
• The skilled employee(s) needed to maintain this infrastructure costs money.

In the old days of the Web, that is, 1995, I remember "business class" hosting was sold for $50 to $150 per month. But some companies today are selling hosting for as little $2.95 a month. And what about free hosting? How do they sell it so cheaply or even give it away?

• Hosting may be a secondary business.
• Advertising is inserted into the hosted sites.
• They offer little or no support to hosting customers.

Real hosting companies needs to make a profit. With the exception of a very few, these low-bid hosting companies are like childhood lemonade stands -- here today, gone tomorrow. They are in the business to make a quick profit and it doesn't matter if they aren't around tomorrow -- to them at least. It is easy to find horror stories of cheap hosting gone bad.

Real website hosting comes from people offering friendly and responsive support on a stable and well maintained infrastructure. This is NOT what you pay for when you purchase hosting for $2.95 a month.

Oh, and if you're looking for "real" hosting, check out Connecting Point. And if you're a photographer, I would recommend Marathon Press. They aren't paying me to say good things about them, but I work for and with both of these companies from time to time and you'll find them to be real indeed.