Archive for June, 2010

Check Out QuickGenerate

1 Comment »Written on June 30th, 2010 by
Categories: C#, Code Quality, Software Development, testing

One of several interesting things in Mark Meyers’ QuickNet project is the whole input generation thing that you need for property-based testing.  It turns out that those input generators are very usable for far more purposes than just property-based testing, so it’s evolved into its own library.  It can generate object instances of almost any kind, while you can still have fine-grained control over the generation if you want to.  You can use it for simple types, complex objects or even entire object graphs. I wish i had time to write a more in-depth post about this, but for now i’m just gonna point you guys in the right direction, and i hope that you’ll see the value in this :)

The announcement of the first release can be found here, and an example can be found here.  Here’s a little glimpse at the code of one the examples:

quickgenerate

I think that piece of code is a nice illustration of how powerful and flexible this is :)

Working Overtime: What It Really Means

12 commentsWritten on June 24th, 2010 by
Categories: Opinions, work/career

One of the things that pretty much every developer has had to face at least once in his career is the issue of working overtime (typically, to meet a deadline). If you're lucky (or smart), this is a rare occasion. For some however, this is either a habit, or happens frequently. There are actually quite a few developers who are proud of being able to do 60-80 hours a week. And they could not be more wrong.

There's nothing wrong with putting in a few extra hours occasionally. Sometimes, it just needs to be done. But, as soon as it is required more than occasionally (and with occasionally, i mean every couple of months), something is wrong. First of all, you're not gonna produce anything good if you're doing a lot of overtime. At first, it starts with a couple of late nights. The first couple of nights, the work you do is still 'good enough'. It's not gonna be great, but hey, it'll do. After a couple of nights though, if you're still doing a lot of extra hours, there's gonna be a noticeable negative effect on the work you're doing. And you know what the worst part is? You, of all people, won't notice it. You're working hard, you're trying to catch up with the schedule, and you're doing the best you can. Or at least, you think you are.

In reality, you are hurting yourself, the project and your teammates more than you could imagine at that time. Here's the deal: there's a reason why most people are working 8 hours a day on average. If you routinely work more than 8 hours a day, your work is going to suffer from it (it depends on the job obviously, but for software developers, i'd argue that this is definitely the case). If you do a bit of overtime occasionally, then you, nor the project will suffer from it. It'll just take a little bit more out of you than what you're used to. But once it becomes a routine, you, as a human being, will start performing worse and worse as time goes on. Inevitably, that deterioration will become very noticeable in your work. And here's the sad thing: you're putting in the extra effort to catch up with the schedule. But by doing so, you're actually performing worse and you're hurting the schedule. Here's what happens: you spend a few late nights at the office. At first, things go ok. You're getting things done and it appears to be working. You keep spending late nights at the office. After a few days (really, it happens that fast), the quality of your work starts deteriorating. And you won't notice it until you get back the next day. So then what happens? You start cleaning up the mess you made the night before. Which only means you're getting even more behind schedule. So then you'll need even more time to catch up with the schedule. But you're already spending this much extra time at work, and the problem only seems to get worse! Well, yeah... that's the whole point that i'm trying to make here. You know what's the best thing you could possibly do in those situations? Go home at 3 or 4 in the afternoon, go have some fun, relax, and get a good night's sleep. You won't believe how much more productive you'll be the next day.

But where is this need to do overtime coming from? I'd argue that, in the large majority of cases, this is due to management mistakes. Either the wrong things were promised to the customer, or your management doesn't have a clue of what is really going on. So, if you find yourself in a position where you routinely need to do overtime, you really need to start asking yourself whether or not you're working for the right company. If you routinely need to do overtime to reach a deadline, that tells you that the project management (and highly likely, every kind of management beyond that) is pretty messed up. I don't know about you, but i really don't want to work for people who don't know what they're doing. If you're doing a lot of overtime, your management is either clueless or stupid. Probably a combination of both.

As for the developers who are proud of their 60-80 hour work weeks... what does that tell you about them? There truly are very few people who can keep on producing great results beyond the regular 40 hours a week. Something tells me that very few of those developers who brag about their extra hours really fit into that category. If they really did fit into that category, they'd let their results speak for themselves instead of needing to brag about the amount of effort they're putting in.

More On System.Tuple And Serialization/Deserialization

3 commentsWritten on June 23rd, 2010 by
Categories: .NET bugs

As i mentioned in my last post, i ran into a serialization problem with a Tuple reference when returning it from a WCF call.  It failed with the typical exception you get when a type can not be deserialized. Unfortunately, the message of the exception that i got is the same as it is when a type can not be serialized, though both situations are actually quite different.  One of my readers left a comment saying that he didn’t have problems serializing/deserializing a Tuple (by the way: am i the only one who has major problems with typing the word ‘tuple’? whenever i wanna use it, i always end up with ‘type’ before i realize my mistake) through WCF. 

So why did it work for him, yet failed in my situation? The answer turns out to be quite simple.  If you look at the Tuple type of .NET 4 in Reflector, you’ll see this:

tuple_dotnet

So it actually is serializable.  The thing is, my client is not a .NET project, it’s Silverlight.  And the Tuple type in Silverlight looks like this:

tuple_silverlight

Silverlight still doesn’t support the Serializable attribute and the Tuple types don’t have a parameterless constructor, so that’s why it can’t deserialize a Tuple instance when it’s returned from a WCF call.  I can’t believe i didn’t think of this earlier since i’ve been bitten by this problem a few more times (not with the Tuple type, but with other Serializable classes) in the past, but then again, i can’t believe something like this still doesn’t work when using .NET 4, Silverlight 4 and WCF 4 together.

My First Request For The Next .NET Version

5 commentsWritten on June 23rd, 2010 by
Categories: .NET bugs

Please, pretty please, make the Tuple class serializable… i just got this exception:

Type 'System.Tuple`2[System.Guid,System.Nullable`1[System.Guid]]' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. Alternatively, you can ensure that the type is public and has a parameterless constructor - all public members of the type will then be serialized, and no attributes will be required.

That’s all… now if you’ll excuse me, i gotta go include a useless DTO in my project.

MSDTC And Microsoft Security Essentials: A Killer Combo!

1 Comment »Written on June 21st, 2010 by
Categories: MSDTC

Just when i thought i had experienced more than a lifetime's worth of MSDTC issues, i ran into another one. All of a sudden, my MSDTC transactions started causing problems on my system again. Now, this happens occasionaly for reasons that i've been unable to figure out. I've learned to just accept it, reboot my system when it happens, and once it's back up it all just works again. So this time, i rebooted my system, waited for it come back up, tried running the same code that failed before and much to my surprise i got the same exception as i had gotten before:

System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException: The MSDTC transaction manager was unable to push the transaction to the destination transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers.

I checked my MSDTC security settings to make sure that everything was still configured correctly, and it was. I then checked to see if Windows Firewall is still disabled, and it was. Then i remembered that i've had problems with MSDTC transactions failing after Microsoft Security Essentials (MSE) had installed updates. Again, when that happens i typically just reboot and everything works again.  Just for the hell of it, i turned off MSE's real-time protection and tried again.  And it worked without problems. I turned the real-time protection back on to see if it would fail again but it kept working. I have no idea what the problem is, but at least i'm now armed with yet another thing to try when MSDTC stops working on my machine.  Gotta love options!

Seriously though, with all the problems i (and others) have run into with using MSDTC, i'm starting to wonder if Microsoft has some kind of covert Make-MSDTC-Usage-As-Painful-As-Possible mission going on somewhere...  Then again, maybe their QA is just getting even worse than it already was.  Oh well...