iKnode: What is in a name?

// November 18th, 2011 // Comments Off on iKnode: What is in a name? // .net, Algorithms, Apple, Architecture, asp.net, cloud computing, iknode

I was recently talking to a friend, and he asked me why I named our project iKnode. He said: “I know you are a fan of Steve Jobs but this is too much”. To be honest, it has nothing to do with Apple or Steve Jobs.

The story begins in 2003 when I was doing my dissertation for my master. I was working for a model to mine data from Data-warehouses to create a knowledge base using Frames and Protegé. I created an engine to do the transformation and mining, at the time I called it IKnow. It was a single engine that only analyzed, and extracted the data to create Ontology classes.

After a couple of years I got interested in distributed systems, and I made the engine run in a distributed fashion and interact with other engines. They could learn to do things, teach others and perform tasks. I figured that code is knowledge. If I wanted the engines to be able to learn and talk to each other they would have to have a common language. I decided to use C# for that. Now I had multiple nodes running on different machines, and I decided to call each node an IKnode. The product as a whole was still called IKnow.

After talking to a friend back in 2006, he mentioned that the name IKnode sounded more interesting than IKnow.  After some consideration I changed the name and the name space of the code. I even bought the  domain. In this same talk, it also came out that for IKnode to be useful you needed a whole team of nodes to perform tasks. And I mentioned to him, jokingly, “There is no I in IKnode”. And then I thought: “But there is an I in IKnode”. And that struck a chord. I thought: “the I is not important, so let’s make it a lower case I”. And that is how the name came to be iKnode. The only letter that is upper case in the name is the K. Which is the whole purpose of the project: Knowledge.

It is interesting to remember how far iKnode has traveled, and how it has grown. I feel like a proud father right now. :D

iKnode reaches Beta status!

// November 18th, 2011 // Comments Off on iKnode reaches Beta status! // .net, Algorithms, iknode, software development

iKnode, our Backend-as-a-Service offering has reached beta status and invites have been sent. We have received a lot of feedback, and we are excited to hear what users think.

It has been a difficult couple of months getting to this point. It was sad, that we were not accepted as YCombinator alumni, but we are not doing this for money or fame. We are doing it for freedom. iKnode is our blackpearl.

If you are interested in checking out iKnode go to iKnode.com and register. If you want to checkout iKnode in action go to our youtube channel. Additionally follow @iknode on twitter.

Here are some screenshots from iKnode’s Command Center application:

iKnode Editor
iKnode Editor
iKnode Dashboard App Execution
iKnode Dashboard App Execution
iKnode Web Console
iKnode Web Console
Execution Logs
Execution Logs
Error Logs
Error Logs

The importance of Trust in Teams

// September 29th, 2011 // Comments Off on The importance of Trust in Teams // Uncategorized

I was reading a thread on HackerNews which really attracted my attention:
Learning the hard way: Moving from NYC to Palo Alto and back in 1.5 months

I started writing a reply to the dicussions and eveything just shifted. Instead of focusing on the article I started to notice how blessed I was to be a part of the iKnode team. I noticed that my reply was not in the spirit of the dicussion, so I cut my comment from HN’s pasted on Emacs, and just posted the following the comment:

I love the article. Thanks for sharing. I have been there before and it sucks.
I think the biggest take-away for me was this line: “early on, it’s about commitment, honesty, and trust.”
And that is why I decided to embark on an startup adventure with my best friends.

It sums up what I am feeling at the moment and it stays in the same direction of the dicussion. I still felt that I had to write about what I think about our team, so I decided to make it a blog post:

These kind of problems is why I decided to go with my best friends to open a startup. I have tried doing a startup before, but I picked my partners by what kind of expertise they could bring to the table. The fact is that, even thought we were a great group of individuals with a great background, we were never a team. We were just that, a group of individuals. Obviously that failed miserably.

Now, with iKnode, I have made better choices. My best friends from Mexico. We all come from different backgrounds and our expertise is very different. But we do have somethings in common: We love to learn, we are obsessed with books and we know how to integrate and work toghether. This doesn’t mean we don’t collide; we do. We just always find a way to solve conflicts.

The fact is: They will always cover my back and I will cover theirs. On our own we are really not that spectacular, but together We are just magnificent.

I have had really bad experiences before too. I have been let down by very smart people who seem to be in the same mindset you have, but then realize we don’t stand each other. The fact is that even thought a team might look so promising because of the knowledge and experience they hold, their execution might not live up to expectations. Having a team, that doesn’t “Know” everything, but knows how to learn is more important, and it is often successful.

What I have learned so far, is that “Knowing” something is really not that important, the capacity to “Learn” fast is. In this article, looking for a CTO that already “Knows” everything you need, is great, but for us is not required. I would focus on trust first.

We tend to look more for general problem solvers, just like ourselves. People that just tackle the problems they are faced with. If we have the knowledge, great, but it doesn’t stop us.

In short, I think when embarking on an startup adventure, choose the people that you would be willing to give your life for, because you probably will.

What tribes are really good for.

// June 23rd, 2011 // Comments Off on What tribes are really good for. // Apple, Windows Vista

The impact of tribes in the tech industry, specifically, is huge, and can be seen easily with the latest release of Apple’s Final Cut Pro X. If you aren’t aware of what the fuzz is about this, you can find about it here, here or here.

It seems the problem is that users are not happy with the release of Final Cut Pro X, an application usedby professional to edit videos and movies. The biggest problem seems to be the lack of features but also the changes in the UI. I am not a user of the application so I can’t really judge. What tihs post is about is Tribes, and how Apple’s tribe makes every single difference in how users perceive changes.

If you read through the news about the topic, there are a lot of bad comments, and the reviews of the application in the App Store are in cases extremely rude. This happened before though, to another company named Microsoft. When Microsoft came out with Windows Vista, their flagship operating system, it was a real backlash, the biggest that anybody has seen in the industry. Even today, Windows Vista is synonymous with Inestability and Failure.

Windows Vista was not a bad product at all, it was actually a great “improvement” in everything, from security to Graphic Design. Innovating in so many things. The problem with Vista was that it forced users to change. The operating system required user to change the way the do things, specially with security. Vista was the right step towards a better operating system, but it wasn’t there yet. Vista was “a true ground-up rewrite with the intention of laying a solid foundation for the long-term future”.

If you read the post by John Grubber, that is exactly what he says about Final Pro X. He mentioned making an analogy of initial Mac OS X with Final Cut Pro X:

“..a true ground-up rewrite with the intention of laying a solid foundation for the long-term future, but, in the short term, lots of missing features and frustrating changes compared to what current users were accustomed..”

This seems a lot like the situation with Vista. The biuggest difference is the tribe. Gruber’s article makes it sound like it is ok for Apple to do this kind of thing, because in the end it may be a better fundamental concept. He also adds:

“This ground-up rewrite may well have been the right thing to do.”

Other comments include:

“Great design, like great music, is almost always foreign at first, if not disturbingly strange. You have to spend time with it. But if it is great, and if you invest your attention, it will change the way you look at the world.” (link).

Robert Scoble mentioned:

“I don’t care what the pros say, I love Apple’s new Final Cut Pro. Agree with @gruber on the topic. Great companies piss off users sometimes.” (link).

I guess Microsoft is a great company, but what is the difference between Microsoft and Apple? This is a big difference in attitute from the Vista backlash. The difference is the tribe. Apple’s tribe accept what the tribe leader does, and even supports it. I don’t really have anything against the Apple tribe, I just think this is really interesting. All critics agreed back then that Vista was the best thing that Microsoft could do, and it was also a step in the right direction. I don’t doubt Final Cut Pro X is also a step in the right direction.

The reaction is very different from waht Microsoft experienced. I guess Microsoft should start listening more to Seth Gooding. Success is not only about making great products, it is about creating a trust with its users. This is really what tribes are good for.

Why I Hate Fix Bid Projects.

// December 11th, 2010 // 3 Comments » // Uncategorized

Recently I made a comment in twitter and to some of my friends, where I mentioned why I hate Fix Bid projects. And it was a surprise to me to hear that everybody disagrees with me. So the general idea is that a Fix bid project can be successful if managed properly.

Define the word ‘Success’. Is it success to be on time and on budget which what we originally planned? If that is the case, then yes, all of the fix bid projects have gone like that for me. The problem is in the definition of Success. It is just like the definition of ‘Done’.

For those who don’t know what a Fix Bid means: It means that a project’s estimation, cost and requirements are all fixed since the beginning. Everything else becomes a change request. Of course, being real, some requirements can be changed without incurring additional cost.

So getting back to the discussion. All the problem resides in the definitions. My definition of a success is when the customer gets her problem resolved. To the fullest extent. My Success is not when I get paid.

The real truth is that companies don’t know in detail what they want. They can sit down and draw images and write big requirements documents, spending millions of dollars in the process. The only way to get Companies to resolve their problems is to do it incrementally. Once Stakeholders start visualizing the end product, ideas start flowing and the REAL requirements come forth.

With Fix Bid projects, this process doesn’t work. Because requirements need to be created before hand, there is no room for change. And you can try and estimate change. But in my experience, estimation is a failed effort if it is done for a period longer than a month. Even the most experienced ones suck at estimation. The reason is simple: Defining the distant future with certainty is not one of our abilities. It just gets too complex to estimate on top of layers that are not built yet. So if we can make mistakes estimating a single task, imagine that scaled to a project estimation.

Of course experienced managers, estimate with a big Risk factor. But even with that, projects go out of budget and out of time. And both parties are left unhappy.  What you are estimating in a Fix Bid project is RISK not the final product. For me that is a failure. The priorities are not in the correct order.

I know a lot of people pay attention to Risk, but for me Risk is a side effect, which can be minimized considerably if you do incremental and iterative development. Each or both ways work.

Doing a project one Sprint at a time, works better. Requirements get cleared for a period of two weeks (approx) and they get implemented. At the end of the sprint the changes are planned for the next release. And continue this way. This reduces risk and in my experience it is also cheaper. The Risk factor is not added to the Budget, and the best thing of all is that the problem is resolved. This doesn’t mean, in anyway that there are no estimates in place for the overall project. They still exists, but they only provide focus and direction. They can be changed.

I understand that there are places where Fix Bid works, but in all projects I have worked, Fix Bid has never been a good idea. Fix Bid projects tend to become Death Marches.

Just to close my rant, I read this in a comment, and I believe it describes what fix bid is:

“The good thing about the fixed bid is that we could possibly make more money, unless something went wrong.” (Link)

Fix Bid is good for the development company, unless something goes wrong of course which usually happens, and then the client gets charged for the risk. If the client is not happy in the end, then a project is a failure for me. Even if I created what I said I would, and I charged them only what I said I would. On budget, on time and according to initial requirements, for me have no value if the solution doesn’t live to expectations.