Automatic dev tools that decrease your productivity

Since the DataSet designer appeared, I do not feel confortable with automatic development tools. They try to make a lot of things while you are working (adding, erasing or modifiying code, files, etc.) and keep a graphical representation synchronized with some kind of struture of code.

It may work in the simplier cases, but when you try to work with them in an enterprise-class application, problems arise everywhere. With the number of artifacts (interfaces, classes, xml config files, etc.), and not necessarily the complexity of the application grows, the automatic dev tools start to fail, doing things you don't desire, like loosing artifacts, getting them de-synchronized, etc.

I'm suffering this with VSeWSS 1.3 WSP View (yes, I know it's a CTP, but I suffered VSeWSS 1.2 before, too): sometimes it deploys ok, sometimes not, sometimes assemblies are not copied to the GAC, modifiying or adding a feature by hand does not reflects on the WSP View, etc. So a tool intended to increase productivity in SharePoint development, introduces long delays (I mean LOOOONG delays) caused by trying to isolate the problem and fixing it.

Someone could say: "By the way, SharePoint development is not an easy work, specially the deployment tasks. It requires to be highly self-organized with your artifacts, and so it is what VSeWSS expects." Ok, I agree with the self-organizing requirement; it is a must when doing the SharePoint's deployment stuff by hand. But I can't agree with the second part. If VSeWSS is an automatic tool, intended to automate SharePoint solutions maintenance and deployment tasks, I believe that have to set the developer free of these task. If it is not capable of handle all possibilities, it doesn't help much.

That's what I expect from a development tool: doing things I usually do "by hand" automatically, in the moment I ask for it. It must be easy to launch and have a non-intrusive behaviour (don't touch or reorganize my stuff!).

In conclussion:

I prefer "myself-driven", simple and rudimetary dev tools that do what I did by hand before, than fully-automatic, code-generating, fully-IDE-integrated, trying-to-keep-synchronized-without-success-diagrams-or-graphical representation-with-code ones. I don't mind if they are command-line tools, or has a lot of arguments. I will spend the time in learning to use it, and use it if it proves to do ok, and with the same results, tasks that I was doing by hand before. I hope in a few time, a good automatic dev tool or designer or whatever proves me wrong.

NAnt rules... Maybe I'm getting old...

Pharmaceutical testing

Some time ago, while creating a virtualized SharePoint development environment, I was looking for service packs, patches and so on, and I found the announcement of the new version of SharePoint product: Silverlight 3.

My first thought was "No, not again! Enough pain, enough dizziness!".

I get explained: in my company, we encorage our technical staff to use, introduce and promote new (stable) versions of the technologies on our projects and developments are based, assuming the risks and problems derived of it.

Usually, once the risks are mitigated (learning curve of the new tech, bug fixes or workarounds, etc.), in the projects which we use this practice, it results into a team experienced in a new technology and ready to be more productive in a new project based on the same technology. The benefit is a competitive advantage for my company.

The thing goes, more or less, this way: The team is initially excited for self-teaching and using brand-new version of the technology, feeling like pioneers taking their own piece of new land to live on and grow it up. Sooner or later (better the first), the team realizes that the new version may require a different approach, what means to throw away an important amount of working hours.

But the project plan and timming doesn't usually matters about new version experiments, so it finally derives in a little anxiety and overwork to finish the project on time (or not too late). This is mostly good for the team itself and for each individual in it, because makes the team and individual members grow in skill and experience.

But the last times, the excitation and anxiety have turned into anger and frustration. New versions or brand new technologies are stable, or bug-free no more. I am not talking about betas, RCs or RTMs. I mean FINAL versions.

Seems that the main IT corporations, those ones that rules our professional destinies and decide our customers needs, have to review their versioning and product launching policies.

They launch pseudo-finished techonologies and products, moved (it's my suppose) by competitive and marketing reasons.

If the new technology or product is satisfactory in the "commercial way of life", it is promoted, revised, service packed and so on until a REAL final version is launched. Otherwise it is discarded, refactored or re-versioned as fast as possible to cover the commercial objectives.

I suffered it all on LINQ to SQL, and later... no, sorry... at the same time, on Silverlight 2.0. With these technologies I felt like a kind of laboratory rat, those with the pharmaceuticals test their "medecines" on... no googled info, no workarounds, no one has... Just the pain and secondary effects on your being...

Now, a new medicine is launched: Silverlight 3.0; hope the leaflet specifies the contraindications and secondary effects that my team suffered with the 2.0 version. The final product is on the shelves of your nearest drugstore...

The case of LINQ to SQL is different... It will be retired from the market: seems like it have not enough contraindications or secondary effects... Better remove the active components that make it effective, and add more addictive and cancirnogen ones. And finally, launch it under a new brand name: Entity Framework...

Just kind a feeling: last times I felt like a guinea pig...

Regards

First post

No ideas, thoughts or opinions to share in my first post... only what seems to be a contradiction:

This box appeared after a failure on web synchronization of a SQL Server Compact subscription to a SQL Server 2008 publication. I thought "successfully", applied to an operation or a process, meant it has finished without errors and NO EXCEPTIONS have raised during it.

This message box (maybe it's tautologic?) shocked me down, and showed how mistaked I was... an operation can be completed sucessfully with EXCEPTIONS... 

Maybe the government will take this theory into account (or not) when I send my incomes declaration to them...

Regards