Philosophy on Tools

February 3, 2009

I’m always very resistant to buying tools for development work, and that is part of the reason that I have not pursued any tools for this migration. The other reason being that, while we are migrating away from Notes, it is intended to be a slow attrition, not an active push to get rid of the platform, so we don’t exactly have a budget to make it happen. We’re just doing what we can with our own internal resources.

In any case, I dislike most tools for two major reasons:

1) They don’t really do anything that a good developer could not have done on their own:

…I don’t like buying a tool when I could write it myself in under a couple hundred hours.  The migration tools that I’ve seen tend to fall in this category. They are slick, and work for many people… but if I can write an ugly simple script that does the same thing exactly as I need it to… why pay money for the fancy version, when I don’t need its functions? It actually make me somewhat angry when another team member recommends we spend thousands of dollars on something I could do myself. My “Developer” personality comes out, and I feel that I am not valued by the team. Tools like this are not only a waste of money, but insulting as well.

2) They tie you to the vendor and/or product:

…SharePoint itself falls in this category, but I’ve already expressed that I do SharePoint as my job, not my passion. One of the biggest roadblocks in getting off of Notes right now is to disconnect ourselves from some of the 3rd party tools that have been put in place in our environment. Some tools are made not to solve a one-time problem, but to fundamentally change how you create your applications, with the tools now embedded in your platform. So it becomes very difficult to stop using a vendor. I have worked in product-based companies, and the leadership was always very exited when we could write features that made the products “sticky” within the customer’s environment. While that is great for the vendor, it is not good for the customer.

These two points alone make me shy away from most toolkits I’ve seen.

But not all — there are great tools in this world. When I find them, I love them. Or sometimes, a tool will still break my first rule from above, but only cost a couple hundred dollars, so it is still worth the money.

I have not had time to deeply investigate all the tools available in the SP/Lotus world. I suspect some tools do fit my criteria as being worthwhile, but I don’t yet know which. If anyone does have any recommendations for tools that are worth their cost, please share in the comments…

2 Responses to “Philosophy on Tools”

  1. Dan Waldron Says:

    Well said Great information, keep up the great work!

  2. Ed Lee Says:

    Totally agree. My experience is that the vendors were showing us tools to do analysis of the current Lotus Notes databases including complexity analysis. They looked great, it showed a list of Lotus Notes databases, document counts, design element counts and so on. However, why do we need to buy a tool to do this? We have catlog.nsf, we can write LotusScript to work out who might be the possible owners based upon ACL access and group management, we can work out possible usage by getting the database user activity, we can work out attachment per document %, we can analyse design as we already have TeamStudio Analyser and score a databases complexity. A decent and passionate Lotus Notes developer can get you all of this given a few days and it saves a lot of money, and that’s what we did :-)

    P.S. Microsoft refer to complexity in a document they call DEI (Design Element Index). They use this to score a Lotus Notes database on how difficult it will be to move to SharePoint


Comments are closed.