Thursday, October 9, 2008

Don't Read This Blog!

When I was 14 years old I was priveleged to have a 9-week mentorship with The Times Reporter, my hometown newspaper. I started my mentorship in the winter, shortly after my friend and classmate Andy Francis had set the bar by writing amazing articles for a 13-year old during the previous fall. Specifically I recall Andy's commentary about Bill Belichik making a bad coaching move during his disastrous tenure with the Cleveland Browns.

Even though I personally sucked at playing basketball, I have been a huge fan of the Cleveland Cavaliers my entire life. During my mentorship, the Cavs had the best record in the NBA for the month of February, going 12 - 1. Also Craig Ehlo earned player of the month honors after propelling the Cavs to a victory by hitting 6 threes against Chicago.

Naturally, I wrote as many commentaries as I could about the Cavs. The newspaper doesn't have these articles available on their website, but I believe my parents have them stowed away somewhere. Then in a sudden change of pace, Ed DeGraw (I think that's how his name is spelled) suggested I write an article addressed to parents on how to act at their child's sporting events. A great concept, but a topic that I was not interested in. I wrote it anyways, then went back to my first love.

The editor at the newspaper, Mr. Dick Farrell, was getting tired of sports articles (maybe Andy was simply a better writer than myself), and asked me to please choose a different topic. So, I wrote an informative article about my views on abortion. Seemingly pleased, Mr. Farrell allowed me to finish my mentorship with a bitter, end-of-year commentary about the Cavs getting swept in the 2nd round of the playoffs by the Bulls (Gerald Wilkins sucks...)

What's the point?

In 1993, I was one of the only 8th graders in the country with the ability to write my thoughts and reach tens of thousands of people. I have much respect for the teacher (MAWS) who initiated this mentorship program.

Today, in 2008, anybody and everybody has a blog. It doesn't matter if what I believe is right, wrong, brilliant, or completely stupid -- I can publish it on the world wide web and somebody will read it.

Here's a science experiment -- go to Google and look up "business blog". How many did you find? In case you didn't do it, I found about 5 million results. I'm sure not all of these results are relevant -- but that is a staggering number of articles out there telling us how to run a business. There are equally as many blogs describing how to lose weight, live happier, have better sex (I hear side-by-side bath tubs on a patio helps), and so on.

Are there that many people out there who have figured out life so much that they are helping others how to live?

A better question is this... Have you ever been in a bar where some guy gets drunk and imparts his drunken wisdom on all of the people around him? How about the news shows where they have 4 "experts" in windows on the screen each with differing political opinions? And for the sports fans out there like myself, you've probably watched Around The Horn on ESPN -- same concept as the political freaks.

If these people are such experts, then why don't they agree? If they have it all figured out and there is one answer to every question, then why do they all have different answers? Why do I keep asking rhetorical questions?

If there was a definitive answer to how to run a better business, or how to have better sex, then there would be no need to have 5 million Google search results. We would have 1 answer -- and it wouldn't matter if you searched for it on wikipedia, urban dictionary, or even the superficial.

Don't get me wrong, I love blogs. However, a blog should be taken simply for what it is -- some person's opinion. This very article is my opinion that blogs are the result of other people's opinions. When I wrote for the newspaper at 14 years of age, I was often exressing my views and not much more. How good my view is might determine how many people actually reads it, but we're not going to find a lot of life-changing information in a blog.

When starting Techspoke, we read many blogs. Some I liked, some I didn't. Some principles I would like to adopt in our own company -- on others I think I'll pass. The point is that by adopting the philosophy of others, we are essentially building a business how they would build a business. Maybe that's not a bad idea if that model is a multi-billion dollar company. But in the end, you've simply built somebody else's dream. You find that one day you are running a company based on their personality, not your own.

So close your browser, take out a piece of paper and a pencil, and write down YOUR ideas. Stop reading mine -- I am as full of it as the next guy. If you want to be successful in business, be yourself and follow your dream. Rob Ratterman of cando.com told me in 2004 to "do what you love, and the money will follow." I like his opinion...

Tuesday, September 23, 2008

Patrick looks like the mouse from Flushed Away

How to assure sex isn't in your future

This guy loves dragons and made his own chain mail. Really? People actually do this?

Anytime you need to feel better about yourself, you can simply click this link and read the story.

Comindwork

We have implemented a new hosted project management solution called Comindwork. You can review the solution here. As an aside, have you noticed how dumb some of the newer company names have become (Techspoke is no exception.) Shouldn't there be some sort of regulation on domain squatters? I digress...

What attracted me to Comindwork was the clean presentation and simple user interface. I had tried out a few different solutions only to discover that they were difficult to understand, were missing key features, or simply sucked (my English vocabulary skills at their best.)

It took about 5 minutes to get set up with Comindwork. Defining our own company was trivial and didn't require a hundred pieces of information when all that is necessary is our name.

Next was setting up our clients. This was as easy as setting up our company -- a couple of fields and that's it. Expecting things to suddenly become confusing, I set out to create a project. Literally, all that is required is the project name, and to specify which company the project belongs. This has to get worse...

Users, Companies, Projects -- all are trivial and take seconds to figure out. Once all of these are created and you have assigned projects to various users, you then discover that each project has the capability of housing Milestones, To-Do Lists, Wiki articles, Blogs, Files for content (SVN compliant), and most importantly, Cases.

Cases are classified into 3 categories: Information Request, Enhancement, and Defect. Cases are what the site refers to as hot-potato, where they are always assigned to a user, and the current user takes an action and either resolves the case, or re-assigns it to another user. Each case supports it's own chat area, with a complete history of every communication and step in resolving the case. The managers can even run a report on case response time.

My favorite feature, and the reason we spent a little more money for the Hosted Workgroup version, is the Client feature. A project can have 3 different types of users -- Manager, Worker, and Client. A client may submit their own cases, and review documents and protected to-do lists. As a manager or worker, I can even assign cases to the Client. It truly turns project communication into a 3-dimensional paradigm.

As a Client, I would have full access to the features set up by Techspoke, because Techspoke is a paying customer. However, if I want to add my own projects, I can upgrade my own account and add my own customers, projects, users, etc. The design behind the site is brilliant because the advertising smacks the Clients directly in the face. And even though I, as Techspoke, may have created the original Client company in the Comindwork database, that doesn't mean I have control over that company. If my Client upgrades their account, I can still only see the projects I am associated with, and the Client uses their system completely independent of me -- even though our companies are linked! Brilliant...

It's been nearly a week since implementing the solution and our workers have begun using it. Now if I could only get the Clients to log in and use the features that I paid for and am so proud of...until then, I will continue to utilize the site and run organized, concise projects.

And the tree was happy.

Monday, September 22, 2008

Stack Overflow

I read an article today on the Joel Spolsky blog about a recently launched website for IT-related questions. He explains it here.

I love the concept of the site because I see the most random questions. A couple of examples are:
What is the strangest/weirdest program you’ve ever made?

How can you program if you’re blind?

Architecture for a business objects / database access layer

Users vote on the answers, and the site automatically moves the highest-rated answers to the top. This isn't necessarily a new idea, but the interface is clean, and they don't charge or scramble answers.

To see the site, you can check it out by clicking here. It's definitely worth a few minutes of your time.

Why Techspoke?

In the spring of 2007 a close friend formed Marketing Activations Group, and called me to see if I could do a few different websites for him. One was his company's site, another was the Rockin' @ Riverwatch tailgate website, and a third was canceled. I had been doing small projects for years, but these were slightly larger than normal, and I felt that it was best that I form an LLC if I was going to be doing these projects.

I asked Patrick Pohler, my roommate and former co-worker if he'd be interested in forming this company with me. He was excited and agreed, so we found an attorney, accountant, advisor, and filed the proper paperwork, and now we're a company.

The funny story about the name (ok, it's not really funny...) is that I came up with it 9 months earlier and wasn't going to use it. The previous summer I was brain-storming names for a side company. My requirements were the name had to be IT-related, creative, and less than 10 characters so that my email address wouldn't be ridiculous. After weeks of searching for techie terms and checking them with domain registrars, I finally put the contractions of Technology and Bespoke together to form the word Techspoke. It's a little stupid, I thought, but it did fit my requirements, so I bought the domain and started looking for more names -- only to give up my quest a few days later. Fast forward to the next spring, Patrick and I were searching names, and suddenly I remembered that I owned this strange domain name. We began discussing the different meanings behind the name and decided that it was still stupid, but better than I had thought, so we went with it.

Things began slow -- we put in a lot of time organizing the internals of Techspoke. Our website, our blog, network storage, remote access, source control -- all of the exciting things that nobody cares about! We launched the Riverwatch website sometime in August of 2007, and we upgraded it this summer. For months, though, we had no projects and wondered if we were really going to grow as a company or simply fizzle out after the first few months. Everybody's dream is to own their own company, but at the time I really didn't care either way which direction we went.

In February of 2008 we kicked off a project for a client in California. We're currently preparing to launch this project in the upcoming weeks. During this project we have added 2 graphic designers from Greenline Creative, and at times have issued the help of another graphic designer and a developer. Check our site often, as we'll be making an announcement at launch.

It's an exciting time for all of us and we are looking forward to continued growth and success.

Brute Force Programming

Describes a primitive programming style, one in which the programmer relies on the computer's processing power instead of using his or her own intelligence to simplify the problem, often ignoring problems of scale and applying naive methods suited to small problems directly to large ones. The term can also be used in reference to programming style: brute-force programs are written in a heavyhanded, tedious way, full of repetition and devoid of any elegance or useful abstraction (see also brute force and ignorance).

The canonical example of a brute-force algorithm is associated with the `traveling salesman problem' (TSP), a classical NP-hard problem: Suppose a person is in, say, Boston, and wishes to drive to N other cities. In what order should the cities be visited in order to minimize the distance travelled? The brute-force method is to simply generate all possible routes and compare the distances; while guaranteed to work and simple to implement, this algorithm is clearly very stupid in that it considers even obviously absurd routes (like going from Boston to Houston via San Francisco and New York, in that order). For very small N it works well, but it rapidly becomes absurdly inefficient when N increases (for N = 15, there are already 1,307,674,368,000 possible routes to consider, and for N = 1000 -- well, see bignum). Sometimes, unfortunately, there is no better general solution than brute force. See also NP-.

A more simple-minded example of brute-force programming is finding the smallest number in a large list by first using an existing program to sort the list in ascending order, and then picking the first number off the front.

Whether brute-force programming should actually be considered stupid or not depends on the context; if the problem is not terribly big, the extra CPU time spent on a brute-force solution may cost less than the programmer time it would take to develop a more `intelligent' algorithm. Additionally, a more intelligent algorithm may imply more long-term complexity cost and bug-chasing than are justified by the speed improvement.

Ken Thompson, co-inventor of Unix, is reported to have uttered the epigram "When in doubt, use brute force". He probably intended this as a ha ha only serious, but the original Unix kernel's preference for simple, robust, and portable algorithms over brittle `smart' ones does seem to have been a significant factor in the success of that OS. Like so many other tradeoffs in software design, the choice between brute force and complex, finely-tuned cleverness is often a difficult one that requires both engineering savvy and delicate esthetic judgment.

link