Posted on 7/30/2009 10:32:32 PM by Justin Etheredge
Sometimes while I am writing code I like to pretend that every chunk of non-trivial code is my enemy. In order for me to be successful in my task, I must not get surrounded by too many of my enemies, or all will be lost. Okay, so I don't actually pretend that, but that would be pretty sweet, wouldn't it? Well, if by “sweet” I meant “nerdy”, then yes, it would be “sweet”. Anyways, I do however try to hide as much code as possible so that I can see the intent of my code, rather than the actual implementation details.
This is an approach which goes right along with the declarative programming fad the is currently going around, where we want to be able to write less ceremony and more substance.
Continue reading the rest of this post...
Posted on 7/22/2009 9:55:22 PM by Justin Etheredge
I seem to always start writing posts on software architecture, and quite rarely do I end up finishing them, much less posting them. I think one reason is that I’m not as much of a loud mouth as some of my contemporaries; as is evident by the lower level of traffic of my blog :-) Also, whenever I start writing something about architecture I always sit back, look at it, and say “man, that really is only applicable to a small segment of the software out there.”
I think that this is the core reason why giving unsolicited architecture advice is so hard. It is even why I have said many times before that I believe vendors (including Microsoft) should stray away from giving generic application architecture advice. Advice never works as well for Bob as it did for Frank and vice versa. That just isn’t the nature of advice, two people will always interpret it in many different ways.
So, I was looking at a recent post that I had been writing on about software architecture, and I was having the same thoughts about whether or not it was worth publishing. It got me thinking about whether or not there was any architecture advice that could be given which was truly universal. I thought and thought and came to the realization that the only constant was that we never get our architectures right on the first try.
Continue reading the rest of this post...
Posted on 7/7/2009 9:02:19 AM by Justin Etheredge
If the title of this post confused you, then you really need to continue reading. There is a technology naming snafu that occurred in the .NET 3.5 release that to this day is still causing serious confusion. I am here to hopefully help people sort out this confusion, and so that we can all move on with our lives. In the .NET 3.5 release Microsoft included a very cool technology called LINQ (Language Integrated Query) and they also release an ORM (Object Relational Mapper) called LINQ to SQL. Thanks to the clever naming of this new ORM, generations of developers will be confused for many years to come.
I think the problem really lies in the fact that the LINQ query syntax looks a lot like SQL, and so people automatically associate it with SQL. Then you throw LINQ to SQL into the mix and people say "hey! This cool LINQ thing lets me query my database in C# code. Neat!" And there you have it, in their mind now, LINQ = LINQ to SQL. And this whole thing could have been avoided, but unfortunately LINQ to SQL is a fairly expressive name (and it fit into their fancy naming scheme), and the guys writing it never really thought that it would create mass confusion. I probably wouldn't have realized this either. Okay okay, I definitely would not have realized it.
Continue reading the rest of this post...
Posted on 7/5/2009 9:59:50 PM by Justin Etheredge
A good friend of mine, Kevin Israel, said on twitter today:
"how freakin long are *we* gonna keep building tightly coupled software that needs to constantly evolve!?"
At first I wanted to say "until programmers stop sucking so much", but unfortunately, there is often much more to the picture than the usual "you're surrounded by idiots" response. Many of us do continue to build tightly coupled software, and we do it for a variety of reasons. Some of us just don't know any better, we've never been exposed to or experienced what exactly people mean by "loosely coupled" software. Others see creating loosely coupled software as another layer of complexity that they just don't need inside of their applications. And yet others, have seen and experienced it, but still don't understand how to implement it effectively. Unfortunately, at this point I think that majority of developers fall into the first camp, they just don't know what it means to build "loosely coupled" software.
Continue reading the rest of this post...