Best Practices on Best Practices?

So the other day I was helping out a coworker on a project and was taken aback by the complexity of the project.  I was expecting a hacky WinForms app with a single form and one monolithic method.  Instead, I saw an organized solution with 6 projects, including a test project.  It took me a good 30 minutes to follow through the logic from one class to the next, across projects and assemblies.  This of course made me feel dumb, so my first reaction was – this project is too complex! 

So while discussing the project with some others to get ideas of what could be wrong, I happened to say - “there’s a time and a place for best practices”.  There was a moment of silence and then I got looks like I had just walked into a courtroom wearing a blue velour suit.  Because of the various reactions, I thought this would be a good topic to discuss with you.

I’ve always been a believer in the “do what it takes to get the job done” camp.  I like to follow best practices until they get in the way.  There, I said it..  I’m not going to hide it anymore!  I believe that a “best practice”, just like most patterns has a certain solution set that it’s best fit for.  I’m not saying throw caution to the wind and forego every bit of programming common sense, but would I use MVVM the next time I want to write a quick utility application?  Probably not.  I follow a rule of thumb – if the pattern I’m using is more complex than the solution the software is supposed to be providing, I’m not going to use it.  It all boils down to ROI – what benefits do I get by following this pattern and how much is it going to cost me to do it? 

Here’s a perfect example.  MVC is getting a lot of buzz right now, and seems like a good solution for a certain set of applications.  Does that make it better than ASP.NET’s classic MVP pattern?  I’ve grown fond of the idea of dropping a control on a form, writing a couple lines of code and being done.  Am I about to dump all of that because MVC is the new hot pattern?  I think you know the answer to that already.  That’s not to say MVC isn’t useful – as I said earlier there is a problem/solution set that MVC is perfect for.  It just turns out, that’s not the problem set I’m normally involved in..

So what do you think about all of this?  Are you a pattern / best practices follower?  Have you found certain ones worthwhile, or vowed never to use a one (or many) ever again?  Leave your thoughts in the comments.

6 Comments

  • Good article.

    been a hot topic on my mind of late. I have a project that falls into each situation you mention.

    so personally i think the best rule, like you say, is just to adopt to each project as necessary.

  • > would I use MVVM the next time I want to write a quick utility application? Probably not.

    Observation: In the last 10 years, most "quick hack tools" I wrote and that proved to be useful became some kind of "permatemp" solution and came back to haunt me over and over again. While YAGNI is often the right thing to do, sometimes it's DOGBITE (do it or get bitten in the end)...

  • I've seen more code disasters as a result of over engineering than under engineering.

    By code disasters I mean unmaintainable code.

  • @Marc - that's certainly something to think about.. how likely is this code to stick around? Here's the way I look at it.. If I spent 30 minutes writing a hacky application and in 3 years find out it's still being used, it might be time to promote it into a real application. But you certainly make a valid point.

  • @SGWellens - I've seen my share of both, and neither are easy problems to solve. In just about every case the best way out is to cut your losses and start over again. Though, that sometimes makes matters worse. The first thing you say is "let's come up with an architecture that ensures that never happens again" and the circle is complete.. :)

  • I don't use classic ASP.NE anymore, for me ASP.NET MVC seems more handy technology even for tiny projects. I think all this stuff is more about personal preferences.

Comments have been disabled for this content.