MacBook Pro iAirTablet

For all of you bleeding edge gotta-have-it folk out there I recently came across some skinny on the next major release from Apple.

Introducing the MacBook Pro iAirTablet
"The Lightest Tablet in the World!!"



Features boast of:
1. State of the art Stylist
2. It's really light!
3. 15" Re-Writable Hard Screen
4. Unlimited Reusable Storage
5. Did we say it's light?
6. High quality Stylist Holder
7. The stylist is super light too!
8. Unlimited Battery Life

Price:
$2400 ($700 extended warrenty program)

Think You Are Too Small?

“If you think you are too small to be effective, you have never been in bed with a mosquito.” -Betty Reese

Let the Code Speak

After having poured over thousands of pages of technical document in my experience in developer land via years of consulting I can't help but plead for the lives of thousands of trees by saying - "Let the Code Speak!"

I never cease to be amazed at the level of redundancy so many people will create for the perceived security in having white-paper documents that spell things out. Naturally these will be printed out over and over again so that people can edit/update/etc. their thoughts on the design.

Generally technical documents are there to document:

1. Data relationships
2. Authorship/versions
3. Installation procedures
4. Requirements (libraries/objects/artifacts/etc)
   
5. Design Compositions (pictures)

In my opinion the whole premise for white-paper documentation is the assumption that "business people" can't read techie manuals and code. They need their "own" copy.

Paaahhlleeeezzzzee! Seriously, if you are a business person in today's world....are you ready for this....you need to either learn, be a part of the development process via conversations and storyboarding, or wait for the prototype/wireframe and just see what it does. But forcing a redundancy is overhead that serves no other purpose than to make you feel like you are in the know even when you will probably never read all of these documents that have to be updated for every change and will most likely become useless as they fall behind development's changes in a crunched timeline (which is all the time).

Additionally, all of these documents have to be changed every single time a modification is made, either to a database, some required library, some user interface tweak. If you are like me, up against inconceivable deadlines, I'm sure you know how likely it is that you are going to put a hold on development just to update some document that nobody is looking at - of course, it's only when you haven't been updating a document when someone comes along and asks if you've been updating documents.

So how can you solve the above required documentation needs via the code? Well, here are some suggestions:

1. Data Relationships - Entity relationship diagrams take forever to actually construct. In the same amount of time that someone can schematic a design, you could just lay out the sql and normalize. If they need an ERD they can generate one from the SQL.
   
2. Authorship/Versions - This should really be handled through the versioning software. There you can find a list of who created, modified, check-out, revised, etc the code (and internal documentation). Hand writing all of this on a white paper document is a clear redundancy.
3. Installation Procedures - These should be a by-product of a README file somewhere if anything and should only come in the form of a note on items that are not inherently specified in the code. For example, you should not have to list the specifics for an Apache configuration since you can just go to the httpd.conf file and figure it out from there. If you are building it for the first time you should be collaborating one-on-one with a developer, not reading his documentation.
4. Requirements - These should be obvious in the code itself, either from the "include" tags, or from comments inserted directly above the particular line of code noting what the library is, etc
   
5. Design Composition - Generally speaking these can just be posted in some location online where people can pull them up to look at them. Including them in a white paper is pretty much useless since they are often resized to fit on the white paper, rather than being the actual size which is more useful when it comes to ascertaining pixel widths/heights.
   

The point is that documentation should come as a result of the development process, not before. The only prior document should be in the loosely formed storyboards (use-cases) that draw out the purpose and use of the software. After all, we all know that the people in the real world will be the ones to actually tell you how they are going to use it. They will do that by actually using, or more importantly NOT using features in your software.

The best place to document is in the code itself, which is already under version control. Everyone is in there anyway, so why not let them know what the heck the code is doing.

And last, as a rule of thumb, if something has already been documented in some location (hopefully the code itself) , then don't repeat yourself by writing the same thing down somewhere else. Instead, become creative on how to find/mine the documentation.

Ruby on DB2 article

I wanted to post a link to a great article regarding working with Ruby on DB2.

http://antoniocangiano.com/2008/02/08/essential-guide-to-the-ruby-driver-for-db2/

Great article, Antonio! Thanks.

Venture Steps

I recently spent a great deal of time reading up on steps for successful startups and decided that I would put out my own rendition for steps - at least from a software venture perspective. These are the steps I have used in working with venture projects in the past and they have been somewhat templatable (to coin a phrase).

1. Investigate Ideas & Choose One (the venture project)
2. Define Your Venture Project (nail it down)
3. Implement & Evangelize (prototype and show & tell)
4. Go Live (release it to the public)
5. Adapt & Improve (review feedback, success, and failures and modify your product)
   

I'll try to develop these more later.

Die Business Plan! Die!

So the question hit me...exactly why am I writing a business plan?

I have spent more than a handful of months trying to lock down on business plans for my different ventures only to discover that for the most point all they did was take up my most valuable asset - TIME! Yes. Time is my most valuable asset. More valuable than anything else I possess.

So I decided I would think through the notion of a business plan here on my blog, listing the quote-on-quote positive reasons for having a business plan, trying to convince myself of why I should have one.

The only actual unquestionable reason for a business plan that I could think of was that investors want to see it. It makes them feel like I know what I'm doing, that I have focus, that I won't waste their money, that I've done my research on the competition, that I know my revenue captures, that I know my corporate structure, yada, yada, yada.

But I don't want investors. I am self-funded. I already know what my market is and there is only one (maybe two) other people involved. We use a collaboration site (basecamp) to record our thinking and conversations, to plan major timelines/milestones, to track todo's, and to house research/intelligence on competition as we come across them. Honestly, having to put all of that into an investor pitch is an overhead that I just don't need at the moment. And I suppose if they really wanted to they could just request access to our site and look around from there. It's all there anyway...in all its 'glory.' Besides, if I'm at an investment posturing position then I really need a prospectus and not a business plan. And if it's an angel investor then it's more about meeting in person than anything else.

It's my money so there is no chance that I am going to blow it on misc expenses. My money is going to pay rent, food, and utilities...and that's it! My car is paid for, I have no mortgage, and a small amount of managed debt so there's no big deal there.

Where research is concerned, how in God's name are you going to know anything about the market until you get out there. I have spent hour upon hour vetting markets only to present it in a plan and have would-be investors/partners gab on about what I don't know and what I should research. Meanwhile, the product isn't getting pushed out there, no revenue is being generated, and I have no demonstrable way to demonstrate (yes I know it's redundant and I'm repeating myself) how in the name of God that the market will in fact respond. At some point you just can't know what the response will be until you try. Might as well get your butt out there and figure it out in three months (while sucking your savings dry in rent) rather than just speculating for the same three months.

Corporate structure? Give me a break. It's me and another guy and we haven't incorporated yet so what's the point.

Ok, ok! I know, I know. Fortune favors the prepared. I'm certainly not advocating that you should abandon reason. But seriously, in today's market, where you have an absolute global competitive realm, the time you spend in the best laid plans of mice (see Hitchhiker's Guide) you could and probably should spend placing your product into the market, if only for one or two people. Then you can review, react, and recreate yourself and your product for the most wild market the world has seen.

So two thoughts on startups...

1. Stay Agile. Don't formulate the business plan right out of the gate.
   
• Put out a rough design including at least two basics:
• Product: What is your product and what problem does it solve?
• Market: Who is your market and why do they want your product?
• Use collaboration, not documentation
• I recommend Basecamp to manage your venture development
  
2. Release Early, Release Often. You biggest obstacle to the market is yourself, not the market. If the market doesn't respond, it isn't your marketing. Um...again...it isn't your marketing, it's your product. It should make sense and the market should want it. Then review, adapt, and improve!

Again, get your product out there. And no time is soon enough.

AND DON'T WORRY ABOUT INVESTORS! (sorry about the capslock...it had to be done) Investors are like laxative, yeah, everything will start moving faster, but you only want to use them when you absolutely have to.