Editorials

Another Delay

Again I am going to delay providing my optimized group by example using Entity Framework. The reason for the delay is that I want to fully implement the framework behind my example so I can prove out my understanding of the code that I write, and the code it generates when calling the database.

So, today I want to drop on you a conversation I recently heard by another Dot Net developer that I thought was a little bit odd. They stated that they “want to write code that is so simple that an entry level programmer out of college will be able to understand it”. I wasn’t quite sure how to react to that statement.

There is a line for how complex an application needs to be. I wrote a simple console application the other day simply to get the user accounts that were members of an Active Directory Group, and then do the converse for one of the users returned by getting all of the Active Directory Groups in which they were a participant. I wrote everything in the static class visual studio creates for a console application, creating two method and calling them from Main. It took me all of 3 minutes, and met all of my needs.

On the other hand, I’m dealing with enterprise applications that have dependency inversion, mapping, domain objects, shared classes and interfaces, and the list goes on. This application has a lot of twists and turns that an entry level programmer will not necessarily be able to follow right out of the gate. This is especially true when a program resolves dependencies through convention instead of explicit or indirect resolution through interfaces and classes.

My point is, how complex does you code need to be? In my opinion, it needs to be complex enough to be easily modified and extended should the need arise. It needs to be testable, and if your tests are automated, then it probably needs interfaces, and injection.

For my Active Directory application, there was no need to do automated unit testing, etc. Therefore, the most direct way to get things done makes the most sense. For an Enterprise application, you need to make it testable, and thus interface driven, and injectable. I’m sure there is room in between as well.

My thought is that if you write everything you do to the lowest common denominator, your applications could be under engineered, and you will experience a lot of extra pain because you didn’t take advantage of capabilities to make your code writing easier, even if it is harder to understand.

Cheers,

Ben

Facebooktwittergoogle_plusredditpinterestlinkedinmail
  • Tim Rivers

    The best bet is to assume that nothing is obvious, and comment the heck out of your code. Describe the purpose of the code block, what requirements are being met and what assumptions are being made, From a high level briefly describe how the algorithm works. The goal should be to write code that can be maintained after you depart the scene of the crime, and comments that help entry level developers become expert developers.

  • John Shadows

    ” if you write everything you do to the lowest common denominator, your applications could be under engineered, and you will experience a lot of extra pain because you didn’t take advantage of capabilities to make your code writing easier, even if it is harder to understand.”

    That is a truism with MASSIVE implications.
    The place where you feel it the most is when there’s an app with a lot of money behind it however the business process it mimicks is not as straight forward as they would have you believe.

    Cash, due dates and program mangers create a tsunami of pressure on you and they all push for a false simplicity in your code that breaks later on down the line.

    Commenting the code ad nauseam just gives even more stuff to read for those who are not all that likely to read anyway. Making classes, methods and properties self descriptive should reduce the need for massive commenting.