Do You Have Too Many Products?

Circumstances beyond my control led me to the Oracle website. It's been a number of years since I used an Oracle database and I wanted to see what they have in the way of rapid application development tools.

Now, why is it that big companies like Oracle, Microsoft, HP, and IBM have websites that are completely impossible to navigate? I think I would have an easier time finding my way out of the Australian outback than finding my way to a product on any of these sites.

How is it that these companies -- industry giants -- have abysmally difficult websites? The budget for these sites probably rival's the GDP of a small country, and for what? Usability? Ha! Accessibility? Doubt it. They spend this money and they arrive at a website that is so difficult to navigate, that one wonders how such a monstrosity could have been contrived.

There is so much fluff and market-speak on these sites that it is truly challenging to get an idea of what they are selling. Does Oracle sell a database server? Does Microsoft have some sort of collaboration tool? Do HP and IBM still sell servers? The answers -- if they exist -- are buried deep in a big ball of mud.

Could it be they have too many products? I mean, look at Microsoft and Oracle. Does every product they offer have their name in front of it because their products aren't unique? And although I think Microsoft's site is very much improved from recent versions, check out this list of "Windows" products:

• Windows 7
• Windows Vista
• Windows XP
• Windows Mobile
• Windows Automotive
• Windows Azure
• Windows Embedded

"Windows Automotive"? Really? "Azure"? And the list of servers:

• Windows Server
• Windows Essential Business Server
• Windows Small Business Server
• Windows Home Server

Apparently, Windows servers aren't essential to small businesses or in the home? You get my point: Too many products.

Back to oracle.com and the impossibility of understanding what products they really offer. A database? Sure. But what's all that other stuff. I need to hire a consultant to tell me what all these products are for.

After a while I was able to find the developer's version of the Oracle database as well as their free IDE known as JDeveloper. I got these things set up and poked around a bit, building a simple JSP page and generally fiddling with the software.

As an experienced systems administrator and programmer, I can see there is a lot of power there, but I am totally overwhelmed by the massive amount of products offered by Oracle. Could I use them? Probably, but I don't have time to figure out which ones I need.

Call me impatient, but I want something that obviously fits my needs. As a builder of things, I understand the desire to create more products and I reckon most of these companies are (or should be) creating products to obtain a competitive advantage. But more products as a differentiator? That I doubt.

Is anyone doing it right? I tried to think of a "big" company with a lot of products. The Apple website is pretty easy to use. But I think Google has the right idea; lay it all out in a simple way; icons, title/link, and a (very) brief introduction.

It is easy for me to sweep aside years of product development and branding, making simple something that is inherently complicated -- and it's not like any of these companies would listen to the likes of me. But this made me examine my own products and websites -- do I have too many products? Do you?

Brandable FTP Client

We've started on a new project called -- for lack of a better name at the moment -- BFTP. It's a brandable FTP client for ISPs and Web developers that will greatly reduce the hassle of providing FTP to customers.

Features include:

• Brandable for each ISP or developer.
• Packages customer FTP info for quick and easy access to a website.
• Web-based control panel for managing customer access.

Remove Your Site from the Wayback Machine

Recently I had a request from a client to remove a site from the Wayback Machine. If you've never heard of it, I suggest you check it out (it is a service of archive.org that captures website content for posterity).

But why would you want to remove your site? Well, because it's your content and your copyright. Or because you don't want a potential employer seeing an old version of your blog. Or because the design of your site in 1997 is just plain embarrassing.

Until this time, I didn't know if or how site could be removed from the Wayback Machine, but I did some digging and found some pretty clear instructions on removing a site from archive.org

It involves:

1. Creating or editing the site's robots.txt file.
2. Submitting a request to crawl the site.

Pretty simple, eh, Mr. Peabody?

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.