다음을 통해 공유


Right vs. Wrong (not)

Someone recently posted a comment about one of my previous blog entries, and their comment in their blog reminded me of a point I’ve been meaning to make for some time:

 

(Cross-posted here)

It's always an honor when someone felt your blog entry was interesting or important enough to do a reciprocal blog entry about... so thanks for the compliment. :) I do sense a little tongue-in-cheek though, so just a few comments...

Of course, 11 servers aren't required to run SharePoint... in fact, many of my customers operate with much less and are quite happy. However, those customers aren't necessarily supporting global deployments with tens-of-thousands of users who's access to the information stored in SharePoint is critical to making the business run. When keeping any system up is of paramount importance, fault tolerance, testing, and clearly defined boundaries and deployment processes are of almost equal importance.

While I don't necessarily expect that everyone in the world will be able or interested in doing what I suggest, my goal is less to give a directive and more to inspire thought. I hope that when people read the blog entry you're referencing they think about what their needs are against those listed and make the decision that is best for them.... and the entry intentionally has enough information to stir those thoughts and help people consciously make those decisions.

Ultimately, I prefer not to think in terms of "right" and "wrong"... and so to that end, not doing the "minimal" infrastructure is certainly not wrong. Rather, there are benefits and trade-offs to every decision that is made, and all too often people make the decision without considering or accepting the trade-offs of that decision.

I hope that when people finish reading my blog they don't leave thinking they're required to do something a certain way... but have enough information to understand why they might or might not need to.

Thanks for the read! :)

It’s important to understand that when when you make a decision to follow or not follow a suggestion or recommendation, you really are making a business decision that has benefits and trade-offs… and you have to decide if the trade-offs justify the benefit.

For example, it is perfectly reasonable to decide that you don’t need a development environment… but you have to accept that either you won’t be doing any development, or that your developers are going to be developing in a production environment. The benefit of not having a development environment is the cost savings that comes with fewer environments to purchase and manage… but the price of that decision is that your production environment will be constantly changing in unexpected ways as developers deploy unfinished or untested code. Likewise, it is perfectly reasonable to say that you do not need to do load testing… but the price of that decision is to not be able to clearly know how a planned change is going to affect the performance characteristics of your environment. Finally, you may also decide that the additional servers, configuration, and expertise required to create a reasonably fault tolerant environment aren’t important to you… but the price of that decision is the risk of your environment going down when any single link in the chain is broken.

Again… none of these are right or wrong… they’re just decisions that must be made, and benefits and trade-offs that must be acknowledged.

The real problem is in not taking the time to truly understand the benefits and trade-offs of the decision you’re making. If there is anything I would say is truly wrong, it is not taking the time to understand what those benefits and trade-offs are. This blog is not about telling you what right and wrong are… it is simply an attempt to give you the best information available to help you make informed decisions. You may make decisions that are different than those that another might make… but at least you’ll know why you made that decision… and the Why is always more powerful than the What.

Stephen… thanks for the reminder. :)