Wednesday, January 31, 2007

Once Upon a Team

Great follow-up by Jeremy D. Miller for The Anti Team. You can find this blog post here. You should give it a good read!

Good teams challenge their approach every single day and keep up a constant dialogue.

This one is my favorite. When a team stops communicating and just continue the coding process day-in and day-out, bad things are going to happen. Having whiteboard discussions is an essential form of communication for a team. This way every one can contribute to the design of software. As Eric Evans mentioned in his essential book Domain-Driven Design: Tackling Complexity in the Heart of Software:

Software development is all design.

All teams have specialized roles for it's members, but overseparation of responsibilities is going to fail in the long run. Communication between team members about design choices is essential in creating maintainable software.

Tuesday, January 30, 2007

What's wrong with ASP.NET

While I was doing the dishes today, I was thinking about the programming model of ASP.NET and the fact that I don't like it (just as don't like doing the dishes). The model it uses for developing web applications just doesn't feel right to me. Now I have to admit, that I don't have that much experience with developing ASP.NET applications, except some small projects with just a few pages. When I finished these projects, I had the feeling that I did a terrible job. The code is wrote is just not that maintainable as I want it to be. I think this feeling originates from the fact that the most important code of a web page is scattered all of the place.

Then I came up with using some presentation patterns like Model View Presenter. This approach results in a more testable design and a better Separation of Concerns. But still I am  convinced that it's too easy to clutter up the code, as this approach requires a lot of self-discipline.

While I was reading my daily portion of blog posts, I came across some rants of another tormented soul:

Microsoft chose to shoehorn an event model onto the web and use a page-oriented implementation. Not only did they get the medium wrong, they also got the model wrong. And this decision resulted in an outrageously complex pipeline processing model with tons of code that is hard to debug or even understand, and that requires lots of high end developers to figure it out and repeatedly explain to newbies what they need to do just be able to do some of the simplest things, things that are brain-dead easy in PHP for example.

I'm glad that I'm not the only one who feels this way.

How can something like Open-Source PHP on Apache take on mighty Microsoft's ASP.NET and IIS, and win? Because they answer the right questions, and they did so in far less than a decade.

I can only agree that the open-source community does a much better job in providing innovating stuff than Microsoft does. A few examples are:

... just to name a few. Using these libraries makes me focus on the Domain Model, solving the real-world problems, instead of focusing on technology. 

I think I'm going to keep an eye on MonoRail as it looks very good. 

PS: I still believe that Microsoft is doing a great job with the .NET Framework: I find that WCF and especially WPF is very innovative.

Saturday, January 27, 2007

Maintainable code

A very nice post by Uncle Bob about rapid software development. We've all done it! Pulling together those quick & dirty hacks in order to meet our deadline. We've created something that works but has messy code and a design that's even worse (= legacy code). We actually believe that we can buy the necessary extra time when we cut corners and rush our way into production stage. NOT!!

The only way to go fast, is to go well.

The truth is out there, and this is it! As described in this post, it all comes down to a matter of professional ethics:

  • True professionals keep their code clean at all times.
  • True professionals write unit tests that cover close to 100% of their code.
  • True professionals know their code works, and know it can be maintained.
  • True professionals are quick and clean.

This covers it all, I guess. This brings us to the domain of writing maintainable code.

A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.

Writing code that works is easy. Almost every developer I've ever worked with can do this. Writing code that works and is maintainable in the long run is very hard and requires a lot of experience and also devotion.

The goodness of a design is inversely proportional to the cost of change.

I've just finished rewriting an existing application. I've got a lot of trouble with reading the existing code in order to figure out what it was doing. This slowed me down a lot. But again, this is probably the reason why I was asked to rewrite this application. Simply because it was hard and too costly to maintain. When something needs to be changed to an application like that, everyone runs out of the room. The fear to break something is taking over.

Creating a code-base that is well designed and maintainable at the first release is a great achievement. Keeping it well-designed and maintainable after many successive releases are heroic deeds. This is were the challenge for us developers lies, not playing around with the latest hype from Redmond or similar. Of course, continuous learning is important but keeping the code clean and refactored all the time ensures that other members of your team don't have to go to a lot of trouble to make changes and implement new features, including yourself.

I'm not saying that I'm already there, but writing maintainable code is one my main objectives. I hope that someday I'll become one of those true professionals.

Thursday, January 25, 2007

The Missing WPF DataGrid Control for Free

The awesome people of Xceed Software are planning to make their upcoming WPF DataGrid Control free of charge. You can subscribe to be notified when it's available.

Monday, January 22, 2007

Which .NET Framework exceptions to throw?

A very useful subject today on the Visual Studio Code Analysis Team Blog called: What exception should I throw instead of the reserved exceptions that DoNotRaiseReservedExceptionTypes warns against?. It's sort of a follow-up to 'The case against catch(Exception ex)'.

I must admit that I didn't know about the InvalidEnumArgumentException class. For checking the enum arguments of my public methods, I always used the ArgumentOutOfRangeException. Yes, I learned something today!

I've seen lot's of code throwing an ArgumentNullException when an empty string is passed to a method. I guess this is what you get when you sneak in methods like String.IsNullOrEmpty into the .NET Framework. I'm very pleased that the FxCop dudes put the record straight:

When validating a parameter that is otherwise invalid (such as an empty string): throw System.ArgumentException

What always helped me a lot is Lutz Roeder's .NET Reflector. Just do what the framework does.

The Anti Team

Another great manifest by Jeremy D. Miller, called The Anti Team. Especially the first one is a very recognizable team role and especially the one I hate most: the non-coding architect.

All my colleagues know that I can keep rambling on about this medieval characteristic, but Jeremy phrases it as clear as it can ever be:

I fully believe that I can do a much better job designing and architecting software as a developer involved in the day to day construction of the code than a non-coding architect of equivalent skill. Put it another way, designs get better faster when the designer has to feel the pain from clunky designs and adapts to alleviate that pain.

And then my favorite sentence of his entire post:

Non-coding Architect is an order of magnitude worse when he/she is a member of a centralized architecture team that is the "keeper of the flame" for the enterprise architecture.

I think I'll save this one.

Friday, January 19, 2007

Validation, validation, validation

I found an interesting entity validation library on CodePlex called EViL. The new Validation Application Block in the January 2007 CTP of Enterprise Library 3.0 also looks very promising. I just had a first look at both libraries and I like the simplicity and easy use of EViL, but I also like the power and flexibility of the Validation Application Block. It's possible to define validation in a separate configuration file that can be modified after deploying your application. I'm not saying that this would be a good thing without some major regression testing, but still, I like the approach of isolating validation rules. I will have a go on both libraries. If you know some other viable alternatives, please let me know.

NDoc 2.0 Alpha vs Sandcastle

I just finished reading Kiwidude's rant about using Sandcastle to generate documentation for .NET 2.0 applications and libraries. I'm using it for a couple of months now and I must agree that it's a lot more work then when using good, old NDoc. Generating documentation with NDoc is also a lot faster compared to Sandcastle. Even when you have a few assemblies it takes about half a century to generate a .chm file. If there wasn't some GUI helper tool like Sandcastle Help File Builder (which is excellent B.T.W.), I've given up a long time ago.

After tweaking some settings and playing around some more, it actually created a help file that I'm satisfied with. But still not even close to what I'm used to have with NDoc. Maybe I'll give NDoc 2.0 Alpha a try, for old times' sake.

I personally believe that writing good documentation is equally important than writing good code. I'm not saying that I can write good documentation, but at least I'm trying (I should give chapter 32 of Code Complete another read). It contributes to the readability of my code and the usability of my libraries. I think I'm not alone on this one, so why are there no better (free) alternatives than Sandcastle? If I've got the time (and the source code of NDoc 2.0 Alpha), maybe this would be a great open source opportunity.