First of all, let's take a look at an image that Microsoft uses on its MVP page:

"Independent Experts. Real world Answers."

This is indeed what the MVP program should be about. It is however the exact opposite of what I and many others in Belgium have experienced. Let's cover the words in those 2 sentences a bit more in-depth.

Independent

Most of the .NET MVP's in Belgium work for a handful of companies that happen to be big sponsors of every important Microsoft event in Belgium. Now, could it be possible that the best .NET developers in Belgium all work for these handful of companies? I highly doubt it. I know a lot of great developers in Belgium and none of them work for these companies. And I'm quite sure that none of those people are less valuable or knowledgeable than any of those MVP's. In my experience, there is hardly anything independent about the Belgian .NET MVP's. Most of them got their first MVP award while they were employed by sponsors or 'strategic partners' of Microsoft. Most of them tout the latest and greatest Microsoft technologies, pretty much unquestioned, even if it means contradicting their statements and positions when they were promoting the technology that Microsoft wanted them to promote 3 or 4 years ago. And they're never openly critical of anything Microsoft-related out of fear that it will negatively impact their chances of being renewed as an MVP. They may not work for Microsoft, but they are anything but independent of Microsoft.

Experts

This is a tough one. What makes one an expert? In some fields, people are considered to be experts based on the amount of research they've done. In other fields, people are considered to be experts based on what they've actually done. I don't think I'm going out on a limb here by saying that in the field of software development, what you've done should be more important than what you've researched or read about. In my opinion, an expert in a specific technology should have built at least one, and ideally more than one, non-trivial system using the technology in question and should be able to tell you about mistakes they've made, things you should avoid, and should never use examples that promote bad practices. I rarely hear MVP's talk about things you should avoid. I rarely hear MVP's talk about mistakes they've learned from. I routinely see examples from MVP's that make me cringe. I routinely hear MVP's promote technologies even though they haven't actually built anything impressive with it. I think of a lot of words when I see examples or proposed solutions by MVP's, but the word 'expert' unfortunately isn't one of them. This also applies to the Microsoft Extended Experts Team by the way. I can only question the validity of such a team if it contains people who are listed as experts of a particular technology when I happen to know for a fact that some of those people have never even used the technology they're supposed to be an expert in in a real world project. Let's be honest here: most of the MVP's and the MEET members simply aren't experts. They are people who have a strong interest in a particular (or more) technology and do their best to promote said technology. There's nothing wrong with that at all, but there's a huge difference between that and being an expert in something.

Real world answers

This one cracks me up the most because most of the Belgian MVP's hardly work on real world projects. And when they do, they typically work on "multiple projects" as they like to say it. For anyone who's ever worked on multiple projects at the same time: could you honestly say that your contributions were truly valuable to the end result? Let me put it differently: don't we all know that people generally produce the best results when they don't have to juggle too many things at once and can focus on as few things as possible? You will rarely hear about a Belgian MVP working full time on a non-trivial real-world project. A lot of them get to spend a certain number of paid hours each week on 'community work', which means blogging, writing articles for magazines, creating presentations for events, etc. When they're not working on that, you'll often find them talking on Twitter about pretty much anything but interesting or demanding work. And of course, their employers will occasionally send them to clients for a bit of consulting here or there, or to do a product demo. Unless these guys are putting in 60 to 80 hours a week (which I seriously doubt), I'm having trouble figuring out when exactly they do the kind of interesting work on real world projects that would enable them to provide answers based on real world experience.

It also doesn't help that I've frequently heard rather unflattering stories about these MVP's from people who've worked with them. It's pretty much always the same: they're not invested into the project, they spend too much time 'interacting with the community' and if you let them go near important parts of the code base, bad things usually happen. Now, I'm not the type of person who simply believes everything he hears. In fact, when it comes to matters like these, I generally only believe the stories I hear from people of whom I'm truly sure that they know what they're talking about. And if you've been reading this blog for a while, you'll know I'm rather critical and that I set the bar rather high when it comes to that.

Lastly, my personal working experience with MVP's has been abysmal as well. I once worked for a client where we had to get rid of 2 people because of how bad they performed in real world circumstances. One of them was an MVP at the time, and now works at Microsoft as an Evangelist. The other wasn't an MVP at the time, but has been one for a few years now and is even one of the Regional Directors of this region. A few years later, I had drinks with a manager of the company they both worked for and he bluntly admitted that both of them are useless on real projects but that their MVP status was a huge benefit to the company from a marketing and image perspective. Not exactly the image or branding I'd be looking to put out there, but hey, to each his own.

Why On Earth Did I Write This?

For 2 reasons. I think this whole MVP thing sets a bad example to young and impressionable developers who aren't sure what to focus on to advance their careers. To outsiders, these MVP's sure look like they've got a great thing going and it's easy to see how that could impress people who don't know better. There are already quite a few developers who suck up to these MVP's in the hopes of someday getting to 'that level' as well. I'd much rather see these people put effort into learning about concepts that will last them a long time and building skills that are transferable to multiple technologies instead of sucking up to the wrong people, and trying to network their way to more interesting work because the work that results from that is truly mediocre at best. By all means, try to make a name for yourself by blogging and speaking publicly. But do yourself a favor and stay true to yourself and favor quality over quantity when considering the audience you want to target. Hey, it worked for me

The second reason is because this whole MVP thing is, in my opinion at least, offensive to the many dedicated professionals who give their all at their jobs as they work on real projects that matter, as they try to mentor younger developers in their workplace, as they try to optimize the way they develop software not only for themselves, but for their teammates and their employers or clients. These are your true valuable professionals.

I'm sure I'm gonna get a lot of flak for this post, but honestly, it won't really make any difference to me. The people who'll be offended are people I'd rather not work with anyway. And of course, I feel quite confident that I'll rarely, if ever, have to deal with these people in a professional setting since I'm primarily interested in interesting and demanding work

I haven't been too happy with the .NET world lately. I've always been somewhat critical of the .NET world, but generally, i felt it was one of the better environments to work in. But there are some things that have been bothering me for a while now, and there are some recent developments that really made me think about the future of this platform. First, i want to focus on the things that have been bothering me since the beginning. After that, i'll discuss the problems that i expect in the future.

One Ring To Rule Them All

As we all know, Microsoft has a tremendously large influence on how software gets developed in the .NET world. For many companies, this is indeed quite convenient. You can stick to the Microsoft Path (or should i say: the One Microsoft Way?) and you'll have all the guidance you can ask for. They provide architectural and design guidance for everything from your database to your business layer to your service layer all the way to your presentation layer. Unfortunately, a lot of that guidance is of a terribly low quality. Follow their guidance and odds are pretty high that either your database implementation details are leaking through all the way to your screens, or that a lot of your business details are taken care of in the database. Depending on how many Microsoft MVP's you've listened to, you might end up with both situations simultaneously.

One of the most important goals of every piece of guidance and tooling that they provide is accessibility. Lower-end developers should be able to use their products and their guidance and be able to build software of an acceptable quality. Unfortunately, a lot of the mess that is produced on a daily basis in the .NET world is the result of that very same goal. And the only people who are (knowingly) suffering from it are the higher-end developers. They are the ones who have to deal with, and clean up the mess. Customers and companies hardly ever realize how much money they're losing on this because this low standard for quality is apparently not only accepted in the .NET world, but also expected. A lot of people simply don't know that the quality of software that we, the .NET community, produce on average is really low compared to other development communities. But then again, that is naturally what you get when you want to lower the bar and try to get everyone involved with developing software. You'd think that after over 50 years of history in this business, we'd have wised up to that fallacy by now, no?

The low quality of the guidance and the tools is the reason why i have started referring to the typical Microsoft recommended development practices and products as Fisher Price Development. It's great if you're into toys, but if you wanna get serious, it's just not gonna cut it. It wouldn't be so much of a problem if the vast majority of the .NET developer community wouldn't just blindly accept everything that Microsoft tells them to do or use. Which brings me to my next point...

Developers, Developers, Developers!

There is a huge difference in quality between the higher-end .NET developers, and the lower-end. The higher-end developers are generally more open-minded to what works in other development communities and want to learn from that. And they want to take what they've learned and apply that in their .NET work. The lower-end developers however will rarely venture beyond the approaches that Microsoft recommends. The higher-end developers generally try to share their knowledge and experience with others, but in doing so, will waste a lot of time and effort going against the backlash they'll get from the lower-end developers. The lower-end developers frequently accuse the higher-end developers for making things more complicated than they need to be, while they fail to realize that their initially simple solutions (as recommended by Microsoft of course) only leads to severe complications later on.

If you think about it, it's pretty similar to the Matrix. You've got a small minority of people who have noticed that something isn't quite right, took the red pill and are continuously going through hardship because of it. On the other hand, you've got a group of people who'd choose the blue pill to go back to a world where they're being spoon-fed a reality that isn't quite real by a system that only wants to keep them in check so they remain in control.

It's just not easy to be a .NET developer who values Continuous Improvement. If you're not wasting time working with people who are quite content with Fisher Price Development, you're likely working for people who're telling you to use some of the Fisher Price Building Blocks because "It's Fisher Price! You can't go wrong with that!". I've been in both situations in the past and it just drains so much energy from you. If you're in neither situation, you are in a very small minority.

The Road Ahead

So what exactly does the future of the .NET platform look like? Obviously, nobody knows. I'll tell you what i expect to happen though. I found it extremely telling that Microsoft is capable of putting resources on products like WebMatrix and LightSwitch (both of which are targeting the very-very-lower-end developers, or even non-developers) while at the same time, they are severely cutting back the resources for projects like IronRuby, IronPython and the DLR (which drew more interest from the higher-end developers than the lower-end developers). So what exactly does that tell us? I can only consider that to be a very clear message that the lower-end developers will always be the primary target of Microsoft, and that they really care less and less about the higher-end developers. When it comes to guidance and tooling, they are continuously displaying that they either just don't get it, or that they just don't care.

So where does that lead us? I think we're only going to get more and more low-quality software projects being developed in .NET due to the increased and continuous focus on the lower-end developers and the ever decreasing focus on keeping higher-end developers happy. A lot of the higher-end developers will simply move to other platforms and communities. Communities where sharing of knowledge and experience is encouraged, instead of hampered. Communities where best practices are based on real world experience instead of being concocted in a few ivory towers by people who've been detached from real world projects for far too long. Communities where there is less low-quality crap that needs continuous maintenance. Communities where there is no One Ring To Rule Them All.

These days, you're an absolute moron if you're still using a relational database. And forget about getting invited to the best parties if you're not developing according to the Command and Query Responsibility Segregation (CQRS) pattern. And if you're not doing Lean then you're really not worth listening to. Oh no wait, talking about Lean isn't hot anymore since the Toyota recalls so we can scratch that off the list, sorry about that one folks.

Now, i'm not saying that the whole NoSQL and CQRS thing is worthless. I actually find them both very interesting. But to all of you who are now pushing these things as if they are the greatest things since sliced bread, i would just like to ask one thing: can we get some more real-world examples? You do use these things in real-world projects before proclaiming that these approaches will fix all (or most) of our current problems, right? You're not just trying to be cool on the internet, are you? Honestly, of all the people that i hear talking about these things lately i only really believe about a handful of them when they say they use these things in real world projects. I'll leave it to you to figure out who the real ones are, and who is just jumping on the bandwagon.

And no, i'm definitely not going to claim that using an RDBMS for every system is the best choice. I complain about databases every day, but i'm not just going to claim that going with a NoSQL database is going to solve all our problems either. I'd actually feel rather silly doing so, unless of course i'd be able to actually back up what i'm saying. Which i haven't really seen happen yet.

The thing is... there simply is no one-size-fits-all approach to software development and it's pretty sad to see that some idiots actually appear to believe that there is. Sometimes an RDBMS makes sense, and sometimes it doesn't. Sometimes MVC makes sense, and sometimes it doesn't. Sometimes DDD makes sense, and sometimes it doesn't. Sometimes CQRS makes sense, and sometimes it doesn't. That goes for every tool, library, architectural style, or whatever other buzzword you can think of. Use what makes sense for what you need, and let's not pretend to be someone or something that you're not, ok?

That’s what happened when i ran the RunMeFirst.bat file that comes with the NServiceBus download. 

What if i actually need msmq_ADIntegrated?

As for the people who are requesting me to connect with them even though they never met or worked with me... what is that all about? Except for two or three mistakenly added 'connections' there isn't a single person in my LinkedIn connections list that i didn't either work with previously or know in person. I'm not into the whole 'networking for the purpose of networking' thing. I've done pretty well without it so far, and i'll continue to do fine without it, thank you very much.

I'm also really tired of the hypocrisy that's going on LinkedIn. I often see former co-workers publishing updates about how they're reading about DDD, TDD, Scrum, and agile development practices in general when i know all too well that they don't really care about these things and they're just jumping on the bandwagon. I've also had it with the whole recommendation thing that's going on there... i have quite a few 'connections' on there with people that i've worked with in the past but that i honestly wouldn't recommend to anyone. When you see them hooking up at a certain new employer or project or whatever, and then see them writing recommendations for each other that are just plain dishonest then you can't help but wonder what value the whole recommendation feature of LinkedIn brings in general. Seriously, 3 of the worst people i could ever imagine working with once recommended each other with raving reviews. Wanna go out of business? Hire these 3 people. They'll get along great since they seem to think the world of each other. It wouldn't exactly be a smart business decision though.

That's the biggest problem with something like LinkedIn. People get to pretend that they're important or really good while in reality, most of them aren't. It's full of phonies, who are more than willing to help the other phonies out. So what exactly, is the benefit of being on LinkedIn? Figuring out who knows who? That doesn't mean anything either since a lot of the people on it are adding connections whenever they can, whether they liked working with you or not. The whole thing is basically meaningless. And if you're good at what you do, you really don't need LinkedIn to help you out.

So i tried to delete my account... except that i couldn't. You can hide your account and make it unavailable by selecting the 'None' option in your public profile options (which i did just now), but you can't actually delete it. You have to mail their customer service to actually get them to remove your account. Pretty sad, if you ask me.

How about you? Are you on LinkedIn? Have you ever experienced any benefit whatsoever because of it?

I've always thought that Intellectual Honesty is a very important trait that every developer needs to have. I also believe that it is too frequently missing in this business. Some people just want (or need) to be right all the time, even if they are wrong. In software development, it's generally in everyone's best interest to go with the best possible solution to a given problem, while still keeping all relevant constraints in account. Some developers have a genuine interest in the architecture that is used and how things should be done. That is obviously a good thing and i wish there were more developers like that.

I'm in a position where i have a lot of influence on architectural decisions and how we should develop our code. But i've never wanted to be the only one who had to make these decisions, nor do i want people to just go ahead with every idea that i have. I want people to get involved with these things. I want feedback. I want to hear ideas from other people that are better than my own. It's better for everyone if multiple people are involved in such discussions and decisions. Get a couple of people together, discuss things, go over the options and eventually pick the best proposed solution no matter who came up with it. That's always been my approach and it always will be. And i truly believe that it's a healthy approach for everyone involved.

But there are always people who either want to be the only one who gets to decide these things, without input from others, or are generally unhappy in their job if they believe their ideas aren't being considered.

My question to these people is: why? Why does it matter if another person's solution is chosen? Why would you need to be frustrated or disgruntled if your solution wasn't chosen? If you're working for a company where your ideas aren't even considered then sure, you have every right to be frustrated or disgruntled (and i should know, because i've worked in such a place in the past). But if you're working for a company where you know full well that everyone's ideas are considered, then you really have no reason at all to complain if your solution wasn't accepted.

Unless of course, you are more concerned about your personal ambitions instead of the actual results. If all you care about is your status, position or whatever you want to call it, then you really are in the wrong business. Sure, there are companies where you can make quite a career out of such an approach, but it's just not healthy. Not for you personally, nor for your employer, nor for your customers. It doesn't help anyone but yourself, and that sure as hell won't last forever.

Be honest, at least to yourself and preferably to the people you work with as well. If your ideas don't make it, then you might need to question your approach (and for some people specifically: your tactics), your real motivations, or perhaps even your skill level. Again: be honest about what you can do, what you can't do, what you know and what you don't know. And learn how to work with other people, instead of simply trying to get ahead of them.

I'd like to end this post with a quote from Dale Carnegie:

Any fool can defend his or her mistakes, and most fools do.

Today, i figured i could replace our custom IOC container (who wants to have a custom IOC container in his codebase anyway?) with Microsoft's Unity container, which is supported on Silverlight. Turns out that there is no way to resolve a component through Unity while overriding one of the constructor dependencies of that component. Bummer.

But wait, Unity is open source, right? So i go over to Codeplex and browse the list of recent check-ins of the source control repository. The last release of this project was on October 28, 2008. It's most recent check-ins are dated July 13th, April 20th and December 1st. With such sporadic check-ins (which are more like periodic synchronizations from Microsoft's internal source code repository) there's no reason to even begin working on a patch because who knows when you'll get a code drop that officially has the patch.

That is, if the project even accepted patches. There were 3 patches submitted, and all 3 of them were declined with an "This project does not accept public code contributions" message.

So let's see... i can request a feature, but there's no guarantee that it will be implemented. Even if it were implemented, i'd have no way of using it until they decide to bless us with another code drop. I also have no way of providing the feature myself and contributing it to the project, unless i keep it privately and keep maintaining it for every new version they release.

I don't care what license they put on it, but you really can't call this Open Source development.

The problem he's having doesn't even have anything to do with the content of the post, yet he keeps asking questions about something that appears to be rather specific to ClearCase (which i haven't used in over 5 years, nor do i have access to the product). It's pretty clear from his first comment that he doesn't even read the information in front of him, so i figured i'd just redirect him to the manuals of the products he's using and not waste any time on it. After all, i do not work on Team City, nor ClearCase and the problem he wanted me to help him with is not something i intend to figure out. I hardly have enough time to spend on everything i want to spend time on, so i'm not just going to try and help everyone with whatever problem they come up with. If i can quickly help you, i definitely will. If it takes me time to help you, i might do it if i actually have that time. But there is no guarantee that i'm going to help you, especially not if you've clearly demonstrated your lack of ability or intent to pursue a solution on your own.

I've deleted any subsequent comments from him asking for Team City assistance. I really don't like that because i have somewhat of a policy of only deleting comments that weren't caught by the spam filter but anything else i never delete. But his comments are just questions from someone who expects me to help him figure out a problem that i really can't help him with. In my first reply, i mentioned that i hardly know anything about ClearCase and that i simply didn't know how he could fix his problem. His subsequent comments kinda annoyed me, but what really pissed me off is a comment that he probably got one of his coworkers (since the IP resolved to the same company) to post, also asking for help with the ClearCase issue he was running into.

So here's a hint: if i've stated that i can't help you, and that i'm deleting your subsequent comments for assistance, then please, seek help elsewhere already. Do not persist, and please don't ask your coworkers to ask me the same question either. If you want help, please exhibit at least some kind of willingness to look into a problem on your own!

I just happened to read the following (who it's from or where i read it doesn't really matter):

When i was learning OOP back in the early 1980s, ...

A statement like that just makes me cringe. Here we are, in the year 2009 and we're all trying to continuously get better at our craft, our hobby, our passion, or maybe just our job. An increasingly larger number of .NET developers are basing their improvement on solid OO principles and practices. And i don't just mean Uncle Bob's SOLID principles. I'm talking about learning from the experience which others before us have gained 20, 30 years ago. How sad is that? I mean, learning from others is great, but how sad is it that all of this great knowledge is something that only a portion of us seek to learn, and usually only after having been active in this profession for a while.

This is an industry where we are supposed to advance rapidly in our way of working, to achieve better results. To produce higher quality software at a lower cost, ideally striking a balance between short-term cost and long-term cost. Yet we are still having difficulty trying to get the majority of us to accept and embrace what others have learned many, many years ago. Oh sure, we might have achieved a higher level of automation within our development process these days due to the availability of more advanced frameworks and tools. But take a look at the principles that are behind most of these frameworks and tools... Most of them have been around for a long time and it's a pretty sad state of affairs that these kinds of principles are only starting to become popular in the year 2009.

Personally, i would put most of the blame with the large software vendors. They continuously hop on whatever bandwagon is popular at the time, while always promising increased productivity with their latest products. You can create a web application just like that (snaps fingers). Want some AJAX goodness? Oh just drag this component on to your web page and voila, you're done! Need Web Services? Just put some of these attributes on top of your methods and there you go! Or better yet, let's just all design some models and generate a whole bunch of code which will save us a tremendous amount of money!

So far, that hasn't really worked out, has it? Yes, most of these 'innovations' increase short-term productivity and best of all, they don't require expensive training and education. Everybody wins! In the longer term, this usually leads to software which is just waiting to be killed off and rewritten and developers who are even more fucked up than they already were.

This has some pretty interesting non-technical consequences as well. What is the general perception of normal people when it comes to the average quality of software that they experience on a day-to-day basis? A lot of people not only accept the fact that software is often buggy or unreliable, they've even come to expect it! Software that crashes? Oh that's ok, just restart it. Weird error messages? Oh that's ok, just click on them and they go away. Is it slow? Well everything is slow these days! I've often wondered exactly how we ended up with this culture of accepted and expected mediocrity. At least there is one benefit: if you're not a complete idiot, you've got a pretty good shot at a successful career in this field.

We're always looking ahead for newer versions of whatever it is that we use, newer tools, approaches that avoid problems that we're currently facing, the silver bullet that is going to solve all of our problems, etc... And that is important, we need continuous progress. It just would be nice if people realized that in order to truly create progress, you need to keep learning from the past as well.

Notice how the team for this particular project at one point gave everyone the finger, and completely stopped caring about the build results.

It seems that even today, in 2008 mind you, we still have a lot of people who are convinced that ORM usage can never be as efficient as the more classic data access approaches. Now, i don't even want to get into the whole debate about where business logic belongs (but if you think it belongs in the database you no doubt have better things to do than reading this blog), but one thing that does bother me tremendously is that a lot of people discard ORMs because they simply don't know how to use it properly.

An ORM is a tool. Nothing more, nothing less. Well, it is a pretty powerful tool and, as with any other powerful tool, improper usage of said tool can really cause a lot of problems. Should we discard the tool because a lot of people never took the time to figure out how to use it properly? That would be kinda stupid, no?

It seems to me that a lot of people seem to have this misconception that using an ORM essentially leads to data-fetching in tremendously inefficient manners. They see the tutorials where only the 'get-by-id' functionality and the lazy loading features are shown and they somehow think that's all there is to it. They hear all the horror stories about projects that performed terribly because the developers used an ORM and they blame the tool, not the developers. Nevermind the fact that there are plenty of projects that use more classic data access approaches who perform like shit as well.

So let's try to get a few of these misconceptions out of the way, shall we?

• You can create highly efficient queries with an ORM tool, and you can actually do so in a manner which enables high developer productivity
• ORM's are not slow by definition. Using them wrong (just like with any other data access technology) can be tremendously slow however. Who's at fault?
• ORM's do not use a shitload of memory. Improper usage of them however can lead to excessive memory usage. Blame the developer, not the tool.
• ORM's do not lead to lazy developers, who are doing lazy coding by relying on lazy loading. Bad developers lead to lazy coding by relying on lazy loading.

So, for those who think that ORM's can never work 'right', i have only one question: are you absolutely sure you know what you're talking about?

Now, there were a few 'hardware changes'. I changed the configured amount of memory for the virtual system twice, and the other one must've been the Parallels upgrade. I wouldn't really consider these changes to be very substantial but apparently Microsoft disagrees with me. The product needed to be activated again. So i clicked the activation link, but Microsoft was kind enough to inform me that this license has been activated too many times.

This license of Windows XP Professional originally came with a Dell laptop that i purchased a few years ago. When i got rid of the Dell laptop, i installed that Windows XP in a virtual machine through Parallels and i remember needing to provide the product key during installation. I guess that counted as the second activation. A while later i had to reinstall because my XP system was completely hosed. That was another activation. And now with the 'hardware changes' in my virtual system, i guess i went over the limit. Very nice of you Microsoft. So i call them to do the activation through the phone... So i type in the ridiculously long activation ID on my phone, and then they asked me some questions. Me being the idiot that i am, i answered them truthfully. One of the questions was "did you have the software installed on the same system it came with?". I answered "no". Big mistake. They told me they couldn't activate it anymore because the license did not allow the software to be run on another system than the one it came with.

So i'm pretty much fucked now... i have no valid Windows XP license, and i sure as hell won't pay for a new one. I'm definitely not paying for a Vista license either. I think Vista sucks horribly so it's not worth the money. And buying a new operating system just to be able to run Visual Studio because i use a consumer-friendly operating system for everything else already? Nah, didn't think so. And how the hell could anyone expect me to pay for a Windows license after Microsoft essentially took away my right to use the software that i had previously purchased? I don't care if the software came with a laptop that i no longer use. I should still be able to run the software on another machine!

It's ironic though... Microsoft wants everyone to trust them. As long as stuff like this is possible, they don't deserve any trust at all. Trust is a two-way street... If they want to be trusted, perhaps they should start trusting their customers for a change.

So today i noticed that a certain number tried to call me 4 times. Of course, i don't pick up. Tonight after work though, i was expecting a call from someone else and i accidentally answered a call from the same number that had tried to call me today. Turns out it was some recruiter.

Him: "Hi I'm So AndSo from DevelopersMeatMarket and i was wondering if you were looking for a new career opportunity" Me: "Nope, not interested" Him: "I actually tried calling you a few times today, don't you even wanna hear me out?" Me: "Not really... I actually try to avoid recruiters, to be honest" Him: "Well, you do realize that recruiters are an important part of this business, right? After all, we're the people who get developers great jobs. Answering those calls is very important for your career."

owkey... if there's one thing i dislike more than dealing with recruiters, it's dealing with recruiters with an attitude.

Me: "Oh really? So tell me, what do you say to your customer when he starts complaining to you that i'm spending too much time dealing with recruiters for my next job?"

At that point he sounds uncomfortable, as if he had no idea how to respond to that.

Me: "Or should i start ignoring other recruiters once i start working for your company?"

Him: "Well, umm... "

Again, silence.

Me: "Right, i think we can wrap up this conversation... good luck finding somebody"

And then i hung up. When will they learn?

• you might be the kind of developer i was talking about and you don't realize it
• you completely missed the point
• you aren't looking at the bigger picture

I don't want people to think that i'm only being negative, so i wanted to clear this up. Now, if you are the kind of developer i was talking about, then i really can't say any more. If you were offended by it, then this blog is probably the wrong place for you. I'm sure you'll find something more interesting to read that fits your goals and purposes more closely.

As for missing the point... some people think that I look down on developers that don't follow the 'ALT.NET' principles. I really don't look down on them. If you go over my post archive, you'll see that i have quite a few 'introductory' posts in there. The whole point of writing posts that introduce concepts to people who don't know about them yet is to try to teach them something new. Why on earth would i go through the trouble of writing 'introductory' posts for people that i suppossedly look down on? If i am confronted with developers that don't follow these practices i usually think they either don't need these practices/principles, or that they simply don't know about them yet. It surely doesn't mean that i think they are inferior or anything like that. Again, if that's what you think, you really haven't been paying attention to most of the things i've been writing about in the last couple of months.

And then there are the people who think i'm merely bitching without offering any solutions. I really think they're not looking at the bigger picture. Do you want a solution to the problem i discussed in my previous post? Here's one: don't hire people like that! They are very easy to weed out during interviews so this really can't be a problem. And if they're already there: get rid of them! Even if you have to pay them severance pay or whatever, it'll be cheaper than the mess they'll leave behind. I currently don't have to deal with them in my job, and i can't even begin to describe how much more productive everyone is if you don't have to deal with all of that. Another thing i can't figure out is that in some places, bad situations like the ones i mentioned in my post really can't be talked about. How could you possibly try to change anything for the better if you can't even talk about the problem? Do you really expect to introduce change without even being open and honest about the problem? That might take years of time, and if you are willing to spend that much time on it just so you wouldn't have to be honest, then by all means go ahead, but don't expect any sympathy from me when you're venting privately. You do have the possibility to introduce change for the better. But if you sit around being quiet and waiting for the problem to go away, then maybe you aren't the right person to introduce changes for the better?

So i guess what i'm trying to say is that sometimes you have to be honest about the negatives if you want it to evolve to something positive. We all have our own ways to try achieve that and not everyone can deal with that. But no problems ever got fixed by pretending they weren't there.

Much like a Vietnam veteran who's suddenly reminded of his traumatic experiences in the war, i too was speechless. Not only that, i was shocked. Chills going down my spine. Didn't all those anti-war protests teach us anything? Why must we revert to all this useless violence? How many innocent developers must suffer needlessly due to these delusions? Why are the wrong people once again making the decisions?

I seriously don't get it... i've been trying to comprehend this for a few hours now, and i just can't. Now sure, i could just "let it go", do my job and not worry about it. Then again, if i were someone like that, i probably wouldn't have a technical blog and you probably wouldn't be reading my posts anyway. See, i'm pretty passionate about software development, more specifically, about trying to do it in a good way. And when i'm subjected to ignorant constraints like these, i shiver. I tremble. I get pissed. I vent.

Still, in this case, there's really nothing else we can do for various reasons i won't get into here. A "standard" data access layer with stored procedures is what they want, so that is what they will get. It's their money, after all. But still, what a stunning display of ignorance and shortsightedness. It's 2008. This myth that stored procedures are the most secure and best performing way of designing your data access layer really needs to be put to rest. I sincerely doubt that any of the much-touted benefits of going with a stored-procedure data layer is actually still relevant in this day and age. Not to mention the fact that it is simply a waste of money. There are much more cost-effective ways of developing software these days and they really don't necessarily mean you'll end up with inefficient data access. Perhaps some day, we will no longer be confronted with delusional constraints that are only based on sheer ignorance. I for one, can't wait. This might actually be one of the few good things about Microsoft's upcoming Entity Framework. Perhaps even the IT dinosaurs will start to realize that maybe ORM isn't all that evil or difficult.

• People have the required skills and motivation to perform their jobs competently
• People are honest about mistakes they make… after all, we all make them so we might as well all be honest about them
• People who play the political game are fired, or if possible, not hired
• People aren't offended when told that something they did was not good or could be better
• People who are sick just stay home instead of infecting others
• It is accepted that developers spend a little of their worktime to read blogs, mailinglists, etc... to learn
• People are judged on what they do, not how busy they look
• People who work together on something are located in the same room
• People have enough common sense to go to a meeting room or a more secluded area to discuss something that is specific to their project, so they won't bother everyone else in the room. If that's not possible, a little bit of voice control would be nice
• People don't engage in Buzzword Driven Development ( = claiming to do certain practices or activities while in reality hardly doing them or doing a half-assed job of them)
• Managers trust the developers
• Managers don't make promises they know they can't keep
• Managers prefer a long-term vision instead of going for the quick short-term win while completely ignoring the negative consequences that will pop up after they have been reassigned
• They have proper airconditioning
• You have access to cheap (or free) drinks and snacks of a wide variety

Unfortunately I was sentenced to Enterprise Hell about 5.5 years ago so I'm not used to most of the stuff mentioned in the list... luckily i'm up for parole in about 2 months!

One of the things that bugs me the most is the .vsmdi file it creates, or better yet, the fact that it keeps creating vsmdi files even though i already have one! I'm sure anyone who's ever worked with MSTest has experienced this issue.

I'd be very grateful to hear answers to the following questions:

1) Why can't it simply use the already existing .vsmdi file? 2) Why oh why has this problem been there ever since the 2005 version was released? 3) Why can't they fix this? i can't imagine this being a hard bug to fix... and i definitely can't imagine needing more than 3 years to fix this 4) Is there anyone within Microsoft who's actually used this crap? 5) Why should i use MSTest over the NUnit/TestDriven.NET combo? Obviously, Microsoft can't even get the integration with its own product right.

Oh and before you ask, you can even get this problem without using source control or read-only files, so please don't suggest that might be the reason

And I must admit, the thought of showing of my knowledge to the world through the same means - a blog - has crossed my mind more than once.

And that probably captures the motivation behind the majority of all tech related blogs: showing off our knowledge. Showing people how smart and great we all are. Who doesn't like to come off smart to his/her peers? Of course, most of us will tell you that we're only interested in sharing or spreading knowledge. And there's definitely a lot of truth to that. But don't let us fool you... it surely isn't the only reason we're blogging about our technical adventures. The other reason is simply Intellectual Vanity. We think we have interesting stuff to say, or interesting content to share, so we do it. And we hope people like it and learn from it. And i'll bet most of us hope people will think we're good at what we do because of it. It makes us feel good when people say "i liked that stuff you wrote on subject X" or "those examples really helped me out, thx!".

To me, there's nothing wrong with that. A lot of great stuff is being produced and shared because of this and a lot of people are learning from it. That's always a good thing. Some people take it too far though. There are some tech bloggers that don't really produce anything meaningful or original. Some of them are just recycling material from other bloggers or are just rephrasing press announcements from large software vendors they have an affinity for. Some of them are just praising whatever new technology comes out without actually giving it a critical look. Don't get me wrong, we don't need to critize everything new that comes out but we should be honest about those new technologies. So why do these people even have a blog? Probably the same Intellectual Vanity that drives the good blogs and the meaningful content. Some people are only doing it for the name recognition i suppose...

A certain developer who used to work on a large project where i worked is a good example of this. He was pretty much worthless as a developer, yet from reading his blog you could get the impression that he's an expert at what he does. Yes, he's involved in the 'community' and is no doubt working hard on his career. He easily impresses people with simple demos of new technology and is making a good name for himself with the kind of people who are easily impressed by fancy 'hello world' applications. But he has about a snowball's chance in hell to become a productive member of a real development team in 'real-life' projects. These are the kind of people who really shouldn't be blogging about technical stuff.

So what kind of blog posts do i like? The ones that are original. The ones that take a complex or relatively unknown subject and make it clear to those of us who didn't know about said subject before. The ones that provide workarounds for obscure bugs we eventually all run into. The ones that offer good advice on how to solve problems we all face. The ones that discuss what doesn't work. The ones that discuss what does work. The ones that show us how to do something. I could go on for a while but i think it's best to summarize it as follows: the ones that provide valuable information for us to learn. There are a lot of great tech blogs out there that are filled with this stuff. I often have a hard time just to keep up with all the great stuff that gets posted.

So you're probably wondering why i'm posting this. After all, it doesn't really fit into any of the categories i just mentioned. Well except that technically it is 'original' since i just wrote this stuff... Anyways, these are just some thoughts about tech blogs that i wanted to share. Maybe some people feel the same way about it

So this is my list of reasons (in no specific order) why you should be writing your tests first:

• It leads to developer-friendly API's. When you write the test, you're already the first user of your class. You'll automatically define an intuitive API simply because you're forced to think about it before you do anything else. This is one of the most underrated benefits IMHO.


• If you do it right, there will be no unnecessary code. We've all been there... you're implementing a feature and suddenly you think of something else you also need to write. A lot of times, that something else you write turns out to be unnecessary. And code that shouldn't be there is a shame. The best quote i ever read about code was something like "code is not finished when there's nothing left to add, it's finished when there's nothing left to remove". I don't remember who originated it, but it's oh so true. This unnecessary code is just a waste of time. That code wasted time while it was being written, and it will continue to waste time everytime it is read. Think about that. How often have you spent time trying to figure out code and you weren't really sure if it was actually being used? If you write your tests, and then only write the code to make the tests pass you should be able to avoid unnecessary code. It's not always easy and it's a matter of discipline but it's really a goal you should be striving for.


• It leads to better code. Code that is easily testable is usually flexible code. Flexible code is easier to change and improve. And the tests back you up while improving the code to make sure you didn't introduce errors.


• It increases the skills of your developers. In more than one way actually. When developers write code, they make mistakes. Every last one of them. The sooner you learn about the mistake, the higher the odds that you'll avoid the mistake next time around. Some bugs aren't discovered until the system is already in production. Often, the developer that made the mistake is not around anymore. How is he gonna learn from the mistake then? He won't. If he has a test that will inform him of his mistake immediately after writing the code, he will have learned something. Just to be clear: i'm not saying that writing tests first will eliminate all bugs. It won't. But it should severely reduce them. Another area where the developers will improve is design. The more tests they write, the more they will learn about creating code that is easy to test. And if it's easy to test, it's easy to change thus indicating good design.


• A code base that is the result of test-first development is a code base that can be modified in a safe way. It allows developers to confidently make changes to code. We've all been in the situation where you need to fix a bug, but you're affraid of changing the code because it's very likely that you'll introduce new bugs. If you have an extensive suite of tests, you should immediately know if you've introduced new bugs. This allows you to confidently make the change you think is the best one. Make the change, run the tests and if everything remains green, perfect! If it turns red, great! You'll know it was the wrong fix before your customers, your manager and your boss knows about it.


• Writing tests first allow you to significantly reduce defects. You'll never write bug-free software. It's very important that you realize that. But you should at least try to minimize the amount of defects in the software you develop. If you write your tests first, you'll not only get instant feedback on newly written code, but you'll also be better protected against regressions in the existing code.

This list is far from complete... these are just the benefits that i can think of at the top of my head.

I'm probably preaching to the converted already, but at least now I can simply direct the uncoverted to this post instead of repeating the same thing over and over again