I have decided to drop out of Microsoft’s Most Valuable Professional Program. I have decided this for many reasons. Mainly I feel the program has no value to me and that MVPs are of no value to MS.

Experts

MS states how they have these “experts” in the community and that are involved in the products. While I have met some really smart MVPs I have also met some that are so out to lunch on things yet MS still considers them experts. To me this completely devalues the MVP program. I am definitely no exception to this. I am a MVP in developer security yet I don’t consider myself to be an expert. Interested yes. Expert no.

The way you get in is by contributing to the community. I had done lots of this and it was really nice to get recognized for it. Once you are in you are supposed to be this expert that provides feedback to the products that MS is building. Now this is where the program breaks down.

Products

Firstly most products you never hear about until it is too late. I hear about more MS technology from the mainstream media than I do from the MVP program. As a MVP who is supposed to be like an insider I thought that they would be looking to us for feedback on these technologies. But they don’t. They will take it after the product is released though but by then there are usually too many issues with the technology to be overcome.

While some products are great there are a big few that still irritate me:

 TFS is garbage if you have used anything else. I should never have to struggle to get things under source control as much as I have with this product. I should never have to struggle for days/weeks to install it. I should never have so much trouble configuring it or applying checkin policies. If any MVP worth their salt was asked about this then MS should know this.

MSBuild is another failed technology to me. It does not come close to the power of Nant so if I am going to pay the XML tax I will pay it with Nant. I will say that it is nice that proj files are msbuild files yet whenever I have had to customize my builds with MSBuild I want to hurt myself. At first I thought it was the learning curve but to me the product just does not meet my needs. Again if an MVP that uses a build technology was asked then MS would have known about this.

MSTest also missed the mark to me when they said it was not geared towards people who do TDD. Really? No one else does TDD? I am the only MVP that does? I think not.

The big one that continues to bug me is Entity Framework. At the ‘08 MVP summit a lot of the MVPs that saw it before it was announced pointed out the serious issues it has. At the ‘09 summit we were excited to see the improvements they had made but instead we were shown the same crap that was the ‘08 entity framework. This spawned off the Entity Framework Vote Of Non Confidence and finally in ’11 we have some of the changes that we said were so needed in ’08. Good job valuing the input of the people that actually have to use the crap you put out.

MS “Listens”/”Cares”

To me it seems that MS having MVPs is a way for MS to feel that they are in touch with the community at large. This is great for a company to do but it seems like the feedback that is given falls on deaf ears for many products. I am not saying that this is for all products though as some do really care about feedback. For the most part though it feels like any feedback given just falls into a void. When I asked for some contacts for TFS/MSBuild/MSTest I was told to send my feedback to my MVP lead and they would forward it on…. Because that is open. You want MVPs to be involved yet filtered (I felt anyways). I have had more interaction with MS staff by tweeting things that I have through the MVP program.

The other big issue I have with MS in general is being treated like we will jump through hoops to help them succeed. There have been a number of “tech x is launching in a few weeks so build something” so we can showcase it emails I have received. Well that is great but how am I going to build a good app on a new technology with little documentation and no access to anyone at MS who can give me some accurate answers to issues? I understand that MS staff are not there to troubleshoot my application but on new/unreleased technology it would be good to have some sort of access if only an internal message board.

There are some internal lists at MS for MVPs as well. I found out about the security one after being a security MVP  for OVER A YEAR. Now that I am on it…. Not much happens. There is little in the way of solicitation for feedback and there is little feedback provided. I assume this is because the security space is pretty quiet but then I am surprised to see things at the summit that I had no idea were being developed.

The most surprising thing to me was when I told my MVP lead that I was not interested in participating in the program. The response was: “No problem.  Thanks for letting me know Dave.  Good luck in the future”. I expected maybe a bit more of a “Why?” response but I am not surprised that MS does not care about what other people think. Maybe, because I have become harder on MS that they are happy to be rid of me. Who knows.

Maybe I am being hard on the program. Our MVP lead is great and tells us that whatever we need he will make happen. Great but how about you let us know some of the things that you can do for us? If you want something like WP7 to succeed get more than 5 dev phones and let us know you have them if we want to build applications. If MS is thinking of a new technology solicit the MVPs for people that use or have an interest in the new tech and get their feedback at the START of development instead of at the end.

Rewards

The MVP award is given to those that contribute to the community. I enjoy doing this and I will continue to do this whenever I can. Unfortunately it costs a lot of time and money to contribute to the community. If I give a talk I have spent 40 to 200 hours preparing (yes 200 hours on a 1 hour talk) plus the costs to travel to another city, food, and accommodation.  MS’s reward is a MSDN subscription and half of a hotel room if I attend the summit (there used to be more benefits but they have been rolled back to save costs). It would probably be more affordable for me to purchase an MSDN subscription on my own and stop speaking entirely. I have gained no additional work from the MVP program, no additional speaking gigs, and have not made relatively few connections to others because of the MVP program.

Fin

The program has become a black mark to me. It does not contain just experts (heck, they let me in). It does not certify that anyone has a clue about anything (and some of the MVP only lists prove this). It has not opened any doors for me. It does not help me stop MS from releasing crap that I have to work with. All it does for me is give me an MSDN subscription and another line on my resume.

One thing I get asked to do a lot is integrate systems with each other or incorporate other systems into one we are currently building. In a lot of scenarios I have been starting to give some pushback on this. Sure integration is cool and all but should it be done?

Expense
The first (and ongoing) issue is the expense of integrating systems. First you have to understand the systems (or at least the APIs being exposed) of each system which can take a lot of time. Secondly we have to write code to integrate the services and adapt concepts from one system to another. This work also needs to be tested and debugged.

Perpetuating The Legacy
The bigger issue I have seen in organizations is that tying a legacy system into your system makes it harder to change or replace the legacy system. If a legacy system has 3-4 systems that depend on it then any changes have to be tested and approved by the consuming systems (expense again).

If we want to replace the legacy system with something better then we have two options. We can either rewrite the system and keep the old API exposed or we can throw it away and force our consumers to change. Rewriting a system and keeping the API may work IF the original API was perfect (or close to perfect). In practice I find that the API is ok but if a person were to rewrite it they could alleviate a lot of the issues and shortcomings discovered over the years. If we do a brand new interface then all our consumers need to change their code which can be…. expensive.

From being in this situation before I have compromised. I created a new system with a better API that was more expressive and simpler to use. I then created a separate project that exposed the old API and translated that to the new API. This does add some performance overhead in translation and lots of things to test (expensive).  It does allow new consumers to use a better API and allowed consumers of the old system to decide if it was worth migrating to the new API.

Integration For Integrations Sake
Many people automatically assume that if the information is in another system that we should integrate the two systems. This does help centralize rules, reduce duplication, and centralize information. This is all true but not always necessary. I would find it acceptable to have some minor duplication if it eliminated a coupling on another system. This is a very careful call to make though as this duplication can lead to duplication of maintainance. Even worse it can lead to their now being two sources of data so when a third system comes along it now consumes both sources for data to try and determine which one is accurate.

One classic example I have is from a client of mine. They have a system that dispatches their vehicles and another system that uses GPS to track their vehicles. They asked for these systems to be integrated as they are always switching between the two. In this case the value of integrating the systems was very low. Instead I recommend that all their operators get two monitors and have both applications open. This is not the 100% perfect solution (unless you are an accountant) but it gets the job done for the right price.

Alternatives
There are ways to integrate but not integrate. One of the simpler ones is to have a button/link/menu item/whatever that fires up a system you would normally integrate with and pass along necessary data. I.e. a button that runs “otherProgram.exe /RunSalesReport 10-10-2009 10-10-2010″ or http://server/SalesReport.aspx?start=10-10-2009&end=10-10-2010. Granted there is a bit of coupling there and some things to maintain but not as much as if we had to call a service, translate the results, and show it on a UI.

Another method is to use manual entry. An example of this would be to use one system to find a product and then type that products manufacture code into your system you are building. Sure it is not as fast and the costs of this slowdown will add up over time but is the cost of integration still higher than the cost it takes for a user to copy/paste a code from one program to another? Not an easy question to answer but one that should be evaluated.

The last method is one typically avoided: double entry. This is where the same (or similar) data is entered into two separate systems. An example of this might be for a sales operation. It may be acceptable for the sales system to have a list of all products, descriptions, and prices of products that they sell. The warehouse system might have its one list of products, dimensions, and inventory levels. As long as when a sale comes in that the order can be filled AND that the sales system does not need to know inventory levels when they make a sale (i.e. if there is none in the warehouse it will just get backordered). This is a very tight line to walk as if an item were entered into one system incorrectly the customer may order 20 Widgets but instead get 20 Gadgets due to the product codes not lining up.

Final Thoughts
I have learned that integration is more expensive than I first thought it would be. I thought that reducing code I had to write would make life easier. It does in some ways but in other ways it adds overhead to development and maintenance. If we just stop and think if it is really necessary to tie two systems together then we might just have a little less coupling and a little more freedom to upgrade some legacy systems. Not integrating is not the only solution…. but neither is integrating.

Recently I have been helping several other developers in the shop I am consulting at and realized another item for this series: Removing Pain. I am amazed by how many times I see developers repeating the same things over and over again.

Builds/Deployments
Builds should be the simplest and most repeatable thing you do in a day. If you have a checklist on your desk of steps then stop and automate. It is such a time saver to have a script that will do the things you need it to do. Wether it is using a build system like nANT, msBuild, finalBuilder, a batch file, or adding automation to visual studio (pre and post build events can be quite handy in a project). I have even used Auto Hot Key to build a macro to repeat some tasks that I could not automate via code.

Coding
Well I am a huge fan of resharper. I probably owe JetBrains about 400 hours of my life so far. There are lots of great tools to help you be productive in your IDE so try some of them out! I am not a fan of code generators but if you are doing tasks that feel like copy,paste, change 1 or 2 things then you should extract it to a generic way of doing it OR if that will not work then look at code generators

Frameworks
There are lots of great tools out there that enable you to do things faster. Things like ORMs for your data access, logging frameworks to make your life easier, and testing frameworks to help you increase or maintain the quality of your code.

If something is painful to do at work that is the first thing you should address. By removing the things that eat away your time you will have more time to be productive and just get more done.

I was going to write an ALT.NET recap article but I think James and Donald really said everything I would have said. Instead I thought I would write about what changed since I got back.

One of the things I came back with from the ALT.NET conference was a lot of renewed energy in that the way I am trying to develop software is the way a lot of talented industry people are developing software. Now not to say that I want to follow what person xy does dogmatically, I want to combine ideas and techniques into what works for me and my client organizations.

A lot of discussions were around our favorite person…. Mort. For those of you that have never heard of Mort he/she is a developer that makes a quick solution to a problem and learns as they go (I am really paraphrasing here for more info check out the Microsoft Personas). Now I must say I hate the term as it used in a derogatory fashion. We all have developers at our shops that do not spend their time reading blogs, reading books, and tinkering with new (or old) ideas and we have to accept the fact that they will always be there. We also need to accept the fact that just because they are not up on all the latest techniques and tools that they still put out good code (well, depending on the quality of the programmer but an Elvis or Einstein is just as capable of outputting garbage code).

One of the common things with the personalities though is that they all learn things. There is no personality type that will fight learning. It is how they learn new things that varies.

One of the things I have resigned myself to is just accepting that I will learn new things ahead of the curve. Others will wait until either MS includes it as a practice / toolset or the organization forces it upon them. How depressing and untrue! Since coming back I have found myself talking with colleagues about a lot of things debated there which has started some good conversations and energy. I have also noticed that me constantly blabbing about x or y and code camp coming up has seemingly built a lot of energy here to want to attend and find out what alt.net is all about or find out what nHibernate does.

I was about to start a really simple task today of creating and retrieving a translation table from our database today. No one here does TDD and I am a one man show on this project (why 7 people come to our project meetings I may never know) so there is not much in the way of pairing. Just before I started I went and grabbed two developers and invited them to come sit down with me and test drive our development down to the data layer. For some reason I was surprised that they said yes and happily sat down for the short time it took to build this out. They asked a lot of good questions about what to test and how to do it so was great to see the gears turning.

The thing I am realizing is that it is not other developers that are the problem. Its that myself and I think a lot of other people that think that no one will listen so we bite our tongues and just do things our way. Granted, not everyone will listen or like what you say and that’s fine! Agile does not work for everyone, UML is not the only modeling language, and drag and drop apps can be successful (I have not heard of one, but I am sure it can and has be done). It’s all about making people informed of different ways to do things and let them choose!

So start talking, sharing, and asking questions! Have lunch and learns. Talk about a problem you have at coffee/lunch. Grab other developers and just show them something that might help them. If they have a pain point in their application give them some advice or sit with them for 10 minutes and show them different ways to do things!