Community Blogs

Time for a little bit of a rant. In a recent post , Jeffery Palermo paraphrases an analogy made by David Platt on a recent episode of the .NET Rocks podcast : In software, we can't expect our clients to know what they need. Much like the depth of a patient may be "I need to get rid of this infection" or "Give me some pills. I'm in pain". Our clients know what is causing them pain, in the business sense, so the problem is from that experience perspective. Some clients might go so far as to ask for some "pills", that is, they might ask for a specific software system that is assumed to solve the problem. I have to disagree. There was a time where I would agree with this statement, but implementing practices...

Last night I was listening to a recent HanselMinutes pod casts where he was talking with Tom & Mary Poppendiek .  For those of you who do not know who Tom & Mary are, they are the 2 behind a lot of the lean software movement (books here & here ). There was a statement made in the episode by Tom that really stuck to me and actually caused me to have a 'ah-ha' moment.  The statement that Tom made was that we as developers tend to refer to business owners as 'The Business' in place of referring to them as 'Our Business'. The difference may seem subtle, but in actually it is quite substantial.  By referring to business as 'The Business' we are making the statement that we have no say or...

A quick disclaimer: we're entering religious territory here. I feel strongly about this issue, but it's certainly my opinion. If you want to get the full sense of how passionate people are about this issue, check out this article at JavaWorld . I've come to the point of view that Entities should not use set mutators ("setters"). Anything you represent as a setter can usually be better represented as a plain old method. Why? Let's remember one of the fundamental guidelines of DDD: intention revealing interfaces. Which is more intention revealing? Customer c = new Customers().Find(42); // This... c.Address = aNewAddressValueObject; // or this? c.ChangeAddress(aNewAddressValueObject); That's a subtle point and it's...

About a year ago I created a few posts on the topic of Developer Ramp time and how companies can help the process as well as why different developers ramp up at different speeds .  Developer ramp time and how companies can aid in speeding up this time is critical not only to a new employee's success, but also that of the team they are joining. This is why I was so shocked to hear a story from a buddy of mine about his company and their philosophy on developer ramp time.  The story goes something like this: My buddy (we will call him Will for this post) has recently been put in charge of the maintenance team at his company.  Currently there are a total of 5 people on this team, 4 developers and him.  Because his team is...

Background - Some people don't like the Entity Framework, some do.  Many see the need to blog about it.  You can guess the rest, or JFGI if your need more info. The debate is nothing new; we have databases that are really good at storing data, searching that data, and spitting it back up.  Problem is the format spit up doesn't play well with how we use the data in code.  So we write some code to translate from one system to another.  If you want to be fancy, call it Object Relational Mapping.  JFGI as ORM if you want. Any skinned cat will tell you, there is more than one solution to a problem.  That's not a problem, that's called choice.  A problem is when one two sides argue over different...

When C# 3.0/.Net 3.5 was released one of the new features that was included was the 'var' keyword. Now I have to admit that when I first read about this new feature I immediately associated this 'var' with the Variant of VB6 or the var of JScript. But that could not be future from the truth. The 'var' keyword was created to allow for anonymous types , these are types that at design time (code time if you will) do not have a concrete type, but at run time they do (compiler creates the concrete type for you). The var keyword is statically typed, it is not a new version of the Variant. Take a look at the code below: // Valid var someVariableName = "Foo"; // this is typed as a string // Invalid var someVariableName...

Many times while you are doing the whole interview dance the company will ask you why you left a former company or client.  But how often do they ask you what you need/want to not leave your NEXT place?  Sure some times they may ask what makes you happy, or what type of place do you like.  But how often to they ask you point blank, what can WE do, what can WE provided for you not to leave this company (assuming you were to hire on)? Over the years of working/consulting for various companies I have learned a thing or two about what I am looking for to not make me leave a company and I thought I would share them. Allow my voice to be heard   As someone how is relatively opinionated (shocking I know) I like to know that my comments...

While putting together one of my last posts one thought kept scrolling through my head.  This was the idea that when you modify your code, you need to make sure your that the intent of your tests still are correct.  I know this concept may seem trivial, but how many of us actually do this. I think most testing practitioners will agree that simply because a test passes green it does not mean that the test is valid and that the code under test is validly tested.  It would not be to hard to imagine a scenario where your tests still pass after you have made changes to the code/class under test, but because your tests still run green you think you are in the clear. Now I know you what you are thinking.  You are thinking that if...

Anyone that is a practitioner of testing or specially TDD knows that the quality of your tests are a direct measure in the assumed quality of your tested code.  Better put, if your tests suck, you can assume very low quality from your code. So what is harder, writing quality code or writing quality tests?  My vote is that writing quality test code is harder then writing quality application code. When it comes to writing 'quality application code' the measure of quality is really in the eye of the developer.  What one person calls good code may be called crap by another developer.  But as long as the code meets the business needs, it should be at least considered quality (if not simply functional) code.  However...

Looks like another Entity Framework barfight! Hell, I'll join the fray started by Jeremy . I feel compelled given that I'm part of the NHibernate Mafia . Ah! Well a-day! What evil looks Had I from old and young! Instead of the cross, the Albatross About my neck was hung. The Entity Framework is the Albatross of ALT.NET . We're forever doomed in podcasts (two I've been on have devolved into this rat hole), blogs, and twitter to have to rail against the machine that is the EF. Let's work toward an elevator pitch, explain why we won't use it, don't believe it will work, and get the hell on with our lives. I remember being in Redmond at the original meeting. Yes it's true that this is the genesis of all this ALT.NET...