July 2006 - Posts
Peter Bromberg posted a good read about the basic rules of development. I happen to agree with all of his points, but there are a couple of them I consider to be particularly significant.
1) A Development Team Should have a Single Design Authority.
I don't think it is by coincidence that Peter posted this one as first on his list. There has been more than one occasion where I have seen the lack of a single design authority lead to a complete mess. It doesn't take long for a system to become difficult to comprehend with 5 or 6 people attempting to mesh together their own designs. For example, try to imagine if everyone on your team used a different approach to data access. Most likely, you wouldn't want to inherit the maintenance of such a system...unless you are a masochist.
It is absolutely critical to choose a single, qualified person to lead the design of a system.
3) Good people build good systems, bad people build bad systems.
I completely agree. When it comes to developers, management often places an emphasis on quantity over quality. You can push all of the best practices in the world at a bad development team and it won't change a thing. Developers that are passionate about their job with a drive to excel are far more likely to build a great system. A team full of apathetic developers is not a group you would want to entrust with the development of a quality system.
Personally, I would put my money on a team of motivated, passionate developers with less experience over a team of arrogant, indifferent developers with significantly more experience.
I have been doing some work with random number generation this week. Specifically, I needed to write a utility that would be used to generate a strong key for a symmetric encryption algorithm. Obviously, there is a wide variety of approaches to this type of task. For my solution, I am using the RNGCryptoServiceProvider to randomize a position in an array of allowed characters. While working on the solution, it made me start to wonder how often people may inappropriately use the Random class for random number generation. I'm sure this topic has already been covered more than a few times, but I am going to throw in my two cents as well.
It is important to understand why Random can cause you grief. The randomization is based on a deterministic mathematical algorithm. If you supply the same seed, it will always generate the same sequence of numbers. In an effort to minimize this risk, it is a common practice to use a date and/or time based value as the seed. When possible, a single instance should be re-used rather than instantiating a new instance each time a random number needs to be generated. This is for two reasons. First, there is an increased risk of generating duplicate numbers when a new instance is used each time. This is most obvious when generating a large quantity of numbers within a brief period of time (less than a second). Second, re-using the instance achieves better performance since there is less overhead involved with a single instance.
Consider the following snippets of code.
// Duplicate Numbers...here we come!
for (int i = 0; i < 100; i++)
{
Random rnd = new Random();
int randomNumber = rnd.Next();
Console.WriteLine("Generated {0} at {1}", randomNumber.ToString(), DateTime.Now.TimeOfDay.ToString());
// Some processing happens here
}
// Ah...this looks much better!
Random rnd = new Random();
for (int i = 0; i < 100; i++)
{
int randomNumber = rnd.Next();
Console.WriteLine("Generated {0} at {1}", randomNumber.ToString(), DateTime.Now.TimeOfDay.ToString());
// Some processing happens here
}Now, don't get me wrong. The Random class certainly is useful for practical randomization. For example, randomizing the order of images for an image rotator could be a good scenario for possibly using the Random class. However, if you need random numbers for the purpose of a generating a password or key, then you are much better served by using a class such as RNGCryptoServiceProvider or another class derived from RandomNumberGenerator. These classes implement a cryptographic algorithm for creating strong random values.
The moral of the story is that all random number generators are not created equal. Be sure to comprehend the differences between them. In doing so, you will be better equipped to make a decision of which one to use based upon your requirements.
The Microsoft Federal Government Developer and Platform Evangelism Team Site has published a series of WCF workshops that can be downloaded here. These workshops are essentially complete demos that give you a guide to working through a lot of the basic WCF concepts. I haven't reviewed all of them, but they look like a good from a glance.
Also, the Federal Developer Blog has quite a few recent posts with additional WCF resources that are worth checking out. In particular, this post has a list of on-demand webcasts that span quite a few topics related to WCF.
If you are interested in WCF, this is definitely a resource to add to your list.
I have been reading Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries. This is already a well-known book within the .NET community and certainly isn't lacking of excellent reviews. However, I have been so impressed with it that I couldn't resist throwing in my two cents as well.
First of all, it was written by Brad Abrams and Krzysztof Cwalina. These guys hardly need any introduction. Brad is a Program Manager for the .NET Framework. He is one of the masterminds behind the design of a lot of the class libraries for the ECMA CLI specification. Krzysztof is a Program Manager on the CLR team. He has also been involved with several of the prominent namespaces of .NET and was one of the creators of FxCop. These are a couple of really sharp guys that possess a wealth of knowledge about .NET. It's hard to go wrong with authors that have such distinguished experience.
The book is a very good read. The intended audience seems to be primarily developers and/or designers of frameworks or class libraries. However, it would certainly be beneficial to any serious developer that just wants a greater understanding of some of the fundamental design of .NET. In my opinion, it should be a required read for any developer that will be writing code used by other developers.
The authors do an excellent job providing practical advice in the form of Do, Consider, Avoid, and Do Not. They cover a lot of important topics ranging from naming, type design, member design, extensibility and usability considerations as well as exceptions and common design patterns. Even if you aren't the type to sit down a read a book like this from cover to cover, it would be worthwhile to snag a copy and hold on to it for reference purposes. If your position involves a lot of design/development of libraries used by other developers, then it would definitely be a good reference to have on hand.
Don't take my word for it. Go out to the Amazon link for the book (see above) and read some of the customer reviews. There are several people that are capable of elaborating the praise of this book far better than I can.
Tonight, I delivered my first WCF presentation for the Birmingham .NET User Group. It was intended to be an introductory look at WCF to cover the fundamental concepts. Overall, I think it went fairly well. The multiple projector failure did throw me off a bit, but it was a fun time. Hopefully, some of the folks got something out of it. I would love to hear that it provoked interest in learning more about WCF (which was the entire purpose). At any rate, I certainly appreciate the kind words of those that told me they enjoyed it...regardless of whether you were just being polite.
As promised, I have posted the slides and code from the presentation. You can download it here. Also, I would love to hear your feedback about the presentation. Did you think it was good, bad, just okay? You aren't going to hurt my feelings. The point is to improve upon presentation delivery before giving another one. Feel free to drop me a line using the contact form on my blog. Let me know what you think.
For the next week or so, I will be under the gun for a client deadline. However, I anticipate a renewed level of blogging within the next couple of weeks. Please check back from time to time for new posts.
Disclaimer:The opinions and views expressed within this blog are solely my own and do not represent those of my employer or anyone else.