20060414 Friday April 14, 2006

The User Experience Extends Beyond the Computer

You only get one shot to keep most customers, and regular customers might give you two chances. Only the most dedicated customers will give you more than that. I‘m done with Amazon. It‘s pretty easy to find what I want to buy, but its a pain to manage my wishlists and account. Worse, there have been two times where I expected a book to arrive in a reasonable time and they couldn‘t deliver. One time I needed a book the next day and I was willing to pay the overnight fees. I didn‘t find out until after I ordered the book that it wouldn‘t even be shipped until two weeks later. At least it is easy to cancel an order. The second time I was willing to wait the week, which after the week was up they told me it would be sometime around May or June that I might see the book. I went to Borders, paid the higher price and canceled the order.

What‘s the problem with this scenario? Supply chain management. Because they can‘t supply the books in a reasonable amount of time, they are losing business. I‘m sure I‘m not the only customer not happy with the state of affairs. I know that you can‘t always predict when a publisher will be able to send you more copies, but for every order you can‘t fill right away is an unsatisfied customer. You really don‘t want them sharing their experience with others do you?

The user experience only begins online, it ends when the product or service is done.

(2006-04-14 23:39:17.0) Permalink Trackback


20060329 Wednesday March 29, 2006

Slow is Relative

I love how people like to compare their software with cars. As if you could compare some web framework with a Ferrari or a Lotus. After all the exotics are so much sexier than a Chevy or a Hyundai. The thing about exotics is that most of the fun from those cars are lost on you if you can‘t run them on a track. A track is a very controlled environment where it is comparitively safer to run your car at full throttle. Most of us live in the real world. Most of us drive our cars with a speed limit keeping us from going wide open.

The same is true of the internet. We have a hard ceiling, which is the speed in which you can connect. The closest thing to a track would be a small network where every device is hooked up with a 1000Gb connection. Heck, maybe even two of them. But even then you have a top speed. It only takes 183KB/s to fill up a T1 connection. Most web frameworks can fill this up without any problems. That‘s 31 users with a 56Kb connection saturated simultaneously. In short it doesn‘t take much. In fact, the T1 is the limiting factor for just about everyone. Its like a 35 MPH speed limit. Most hosts limit you to a certain amount of traffic a month, so if you put 27MB/s as your 75 MPH speed limit (interstate highways) you can fill up a 4GB monthly limit. That‘s 226 Mb or 150 times the speed of a T1.

Nonetheless, you still have a large number of frameworks that can fill the bandwidth. The real determining factor at that point is what does it cost for the bandwidth. That‘s not only the ISP costs, but also the hardware costs. If it takes three web servers to fill the bandwidth, factor that in. Unless you are serving up monster sites like Yahoo, Google, and CNN then more than likely the number of boxes will stay small.

The next thing to consider in the whole Total Cost of Ownership (TCO) equation is the cost of change. All change costs something, but the end gains typically outweigh the costs. For the cost of change, you have the learning, development, testing, and deployment costs. Java usually has an advantage on the deployment costs, and testing costs are typically a wash (the same for just about everyone). More often than not, the cost of development is more important than any of the other costs. If you can develop features quicker, with fewer bugs, using fewer people, then that is far more significant than deployment times. The users will get the features they need, and you can have a competitive advantage. Would you rather pay $220/hr for a week or $120/hr for two weeks to get the same work done (that‘s $800 difference)? How about if the new feature will attract 10% more paying customers every week? Hmm, it‘s out a week earlier and it costs less for the same feature? It‘s a no brainer.

The bottom line is that it shouldn‘t matter if a company chooses to use Ruby on Rails, Cocoon, PHP, etc. as long as they can keep up with demand. If a technology proves itself to reduce time to market, and allows you to do more for your customers with the same amount of money, then by all means embrace it. Change is good. It brings more opportunties than risk.

(2006-03-29 14:10:12.0) Permalink Trackback


20060307 Tuesday March 07, 2006

The D-Haven Promise

The D-Haven promise, its brand, is to work with the customer to build solutions that they need. It‘s our job to find out exactly what it is you need. Personally, I hate the word solutions mainly because it sounds like marketing speak. It applies here, because we don‘t just provide software. We find new ways of helping you achieve your goals. We investigate how to get companies to work together, the most unobtrusive way to get the right information to the right people. The whole “thing” is the solution.

I really need to get the commercial information up on the web site ASAP. I‘ve been working on a strawman site for a while, and I need to just finish it. It‘ll start out a bit cheesey with the text up there, but at least the look will be nice. This is just too long.

(2006-03-07 10:23:58.0) Permalink Trackback


20060228 Tuesday February 28, 2006

Working on my first product

My first product is really designed for me. Its a project management tool. Yes, I know about Trac and Backpack and they are useful for communicating information with clients. However, I‘m focusing on a different emphasis. I want a unified tool that will support the way I think and design software. That means that in addition to your traditional project and articles, we will have goals, todos, user profiles, user stories, etc. I want the design of the application to be very visible. I want to be able to type my thoughts and manage them in the project.

Consistent with my philosophy and experience with project management software is an emphasis on reporting. I want to be able to generate a beautiful design document for the project at the touch of a button. I want to be able to show the progress that I am making as I‘m addressing the client‘s goals. When I have enough of this project management tool done, I will host it on D-Haven.org to manage my open source projects.

I‘m using tagging in a new way, a slight evolution to tie things together. In essence, some of the tags will have a specific meaning. The Project tag is derived from the project name. Anything marked with the project tag is associated with it — from goals to articles. Certain tags will be by convention such as language and framework tags — but they are no different from regular tags.

There are some things I haven‘t decided on, such as what to name the agile project management tool. I‘m developing it for me first, which means if it doesn‘t satisfy me it couldn‘t possibly satisfy anyone else. I will have to move the project into a protected company SVN repository, while I believe in open source software I‘m planning on making money with this project. Parts of it will likely make its way into open source such as any acts_as... code I develop to support it. And yes, I will blog about portions that I am working as I have in my last couple of Rails related posts.

(2006-02-28 10:54:40.0) Permalink Trackback


20060221 Tuesday February 21, 2006

There is Hope Yet

Life never ceases to amaze me. I may be close to getting a paying customer already, and without going into any details, it happened in a way that supports The Clue Train Manifesto. Because I have no preconceived notions of business, nor anything more than Economics 101 education wise, I think D-Haven will eventually become seriously relevant in the coming years. I‘m not trying to take over Microsoft, I just want to make life better one business at a time.

D-Haven will matter for a couple of reasons: a commitment to investing in the future, and a commitment to changing the way we think about software. You can tell by many of my posts on software development lately that there aren‘t many hard hitting how-tos. It‘s mostly my current thoughts on software design, fresh approaches to doing things, etc. I see that as an important way to educate people about how life can be. Why let Apple take all the good ideas?

It may be tempting to seek out venture capitalists and put together a package where I create some products that I hope people use. I don‘t intend to do that. I intend to start with contracting to build relationships. Its existing customers that give you repeat business. I plan on growing out of the initial contracting stage as I build up some capital and purchase some equipment.

The conventional wisdom here is to write a business plan on just how I expect to grow. The purpose of the business plan is not to attract money, but to carve out a path for D-Haven. I like Guy Kawasaki's guidance on business plans. I‘ll be writing it for me, not for a VC. If you don‘t plan it, how do you know whether you are on track or not? I need to do this sooner rather than later.

(2006-02-21 00:03:05.0) Permalink Trackback


20060213 Monday February 13, 2006

My focus for D-Haven

My focus/vision (whichever you prefer) for D-Haven is business automation. So what is business automation? Quite simply put, it is letting computers take care of tedious tasks and letting the company do what they do best. In short, it is helping a company‘s infrastructure to get out of the way. There are several disciplines involved with this type of activity. First, you have to get to know the business you are helping in a short amount of time. Next, you have to find the major problem areas. Lastly, you have to design a solution that fixes things.

People are the face of any business. Jan, the receptionist, shapes how people percieve the company based on her phone manner. Bob, a support personnel, has much more of an influence. Barbera, the warehouse manager, helps maintain the reputation of the company. Each person has a face, a personality, and a way that they like to work. To better understand how to create a solution that saves the company money, you have to understand people. The better you are at that, the better the company will like what you do.

Problem areas exist all over the place. They vary in size and impact from minor annoyance to major obstacle. The key is to find out what is going on without implicating anything else than process. That‘s where metrics come in. Adding metrics behind the scenes (IOW without human intervention) is the most reliable way to find out what is happening without the fudge factor. It might be that Barbera is double-shipping some orders because the warehouse software requires you to manually type in that something was shipped. Maybe moving to RFIDs will help automate that process and cause fewer problems there.

Once you have a big picture of what‘s happening, you can start figuring out what kinds of solutions are really needed. More than likely, the company will need some software to be written. Quite often, they will need to get different systems to talk to each other. One example would be when marketing closes the deal and gets the contracts signed, the customer information is automatically propogated to the accounts receivable system.

Bottom line is that I have been the victim of heavy processes requiring a large amount of human effort to support. I can see several ways of how they can be improved to rely less on people. When the process relies less on people to support it, then the people can be more productive doing what they were hired to do. In the end, it makes it much more enjoyable for everyone. My clients will have an improved bottom line, happier employees, and hopefully better customer loyalty.

Of course, part of this vision is a commitment to short and long term R&D. There should be some improvement every year in what we can offer. I want to make things better. I want to have the lattitude to try new things. Having an R&D program let‘s me try some stuff that will likely fail without affecting my customers. It‘s important to take risks, but stupid to be reckless with them.

(2006-02-13 12:12:49.0) Permalink Trackback


20060207 Tuesday February 07, 2006

How the heck to do start this thing?

Here I am in my mid thirties with a family trying to get a software company started. I‘ve been thinking about this for years, and I believe it is time to do something about it. Last year I got all the legal stuff done, registering the name, taxes, etc. However, I‘m still employed by CITI and I have no time for marketing or building my business. Sure its tough keeping the different aspects of my life in balance, but I believe it is doable.

I‘ve always had a passion for Research and Development, and I envision a company that encourages — maybe even requires — different levels of R&D in all its technical employees. That‘s why I named the company D-Haven which is short for Developer Haven. The logo I commissioned reflects my persuit of simple elegance. I believe I have a lot to offer, but I know I am going to need some help getting started.

I‘m great at software, but not too business savvy. Oh I know enough not to get burned, but as far as marketing goes I‘m a newbie. I actually think that this is one of my strengths and weaknesses. It means that I will be forced to be honest with folks. If I honestly think something is great then that‘s what I‘ll promote. I really need to get a team around me. For the types of things I want to do, I need a relatively steady flow of income. You can‘t get that with contracting alone.

I don‘t want to chase down venture capital because I don‘t trust the venture capitalists. They want me to have an exit plan. My exit plan is to have D-Haven self-sufficient, living and competing among other companies. I don‘t want my company to be bought out by someone else — particularly because I know the first thing to go is R&D.

I don‘t see any way to pull it off, but my ideal would be for D-Haven to be other company‘s R&D outsourcing. With an eye on short, medium, and long term goals R&D is the only way we can come up with the new revolutionary ideas. The only companies that seem to be investing that way are hardware companies. Either software companies are too small, or too risk averse to think outside the box. By amortizing the cost of R&D across several companies it would give those companies an opportunity to invest in the future without absorbing all the cost or risk themselves. Of course to attract the clients that can keep D-Haven running long term, I would need some respected employees which I can‘t afford yet. The whole chicken and the egg problem.

(2006-02-07 12:41:28.0) Permalink Trackback