I generally operate from the position that code must have a reason to exist. If it doesn't have a reason to be there, or be at this particular place, then it should be deleted, and I don't think twice about deleting code. So I tell my team that every piece of code you write must have a reason to exist, preferably a technical one, and one we can defend if people ask Why is this here? Today, this theory (and my blind faith in my own assumptions) nearly got us in trouble.

We're rewriting an old WebForms app into MVC. This is one of many rewrites we've been doing, and I'm the lead programmer on this project. The requirements for this rewrite specified that we were only rewriting the business code, and that we needed to use the database that already existed without modifying it. So, a code-only rewrite, something that we've seen plenty of times. We're still doing our best to upgrade where we can, and to uphold our team standards for well-designed, well-crafted code.

A coworker of mine has been doing most of the programming for this project and I've just been planning out the tasks and reviewing her work. During one of these reviews, some code I ran across tripped my arbitrariness alarm:

public string ProjectTitle { get; set; }

public string PhoneNumber { get; set; }

public string Note { get; set; }  

Why were we putting string lengths on these fields? Seemed to me that this restricted the user unnecessarily. What if they needed more than 500 characters to write a note, since that was going to be a varchar(MAX) in the database anyway, as it had been with nearly every other app? Having converted several old apps from WebForms and being somewhat familiar with how these old apps were written, I assumed this was some naive attempt by the prior developer to impose some validation on these fields.

So I, as the lead programmer on this project, asked my teammate to remove the StringLength validation attributes, assuming that they were not necessary. She countered, saying that the old app implemented those length restrictions, so shouldn't we do that too? I overrode her, saying that no, we were trying to improve on the old app, and why restrict what the user can do unless there's a reason to do so? I told her I wanted a technical reason why these length restrictions had to exist, otherwise I wanted them removed. I was obviously thinking there wouldn't be any restrictions, so we'd just get the extra attributes thrown out.

Except she found the technical reason. The database that stored these values was restricting their length. It had, in fact, specified lengths that matched exactly what was specified in the StringLength attributes.

This threw me for a bit of a loop. I could pick out all the reasons why these lengths didn't fit with my ideal design, including the fact that our team standards say that fields which allow the user to write multiple paragraphs (like notes) should always be varchar(MAX). And why 20 characters for a phone number? Why not 30, or 12, or 100? Why did we have to restrict these values at all? It just didn't make sense to me, and frankly, it still doesn't.

But my opinions didn't matter. I didn't do the research, and my naive assumptions nearly introduced a bug that would have been a big problem had we let it get to production. The decision had already been made for me. I needed to work with the database that was already in place, and there was a technical reason to have those validations, so they needed to be there. So, reluctantly, I had her keep the StringLength validations.

The point is that, even though code needs a reason to exist, you don't have to like that reason. That reason is not beholden to your assumptions or lofty ideals like well-designed code. Sometimes those pre-existing decisions just are and you have to go with it. The key is to try to notice when you are making assumptions, and then check and make sure they are correct, because when you assume wrong, well, you know what happens.