IT and Development Best Practice: Just Because You Can Doesn't Mean You Should..

One thing I have learned over the years in IT and Development is this: Just because you can do something doesn’t mean you should.

What does this mean? It means that sometimes software and programs and hardware will let you do thing/configure things in such a way that is possible in the software, but that doesn’t mean you should do it.

Some examples:

1) Development – You can add a gazillion button controls to a form. Your development IDE doesn’t complain at all. You run your program and it totally dogs or has weird issues. Why? Because common sense tells you that shouldn’t put many controls on a form, you need to redesign! Some guru’s (Aaron Ballman, Raymond Chen) on the subject have blogged about this and it is talked about all around the web

2) Networking – Windows 98 (and other OS’s – I just know this one is from example) allows you to set two gateways on your adapter. Does this make sense? Two DEFAULT Gateways. Shouldn’t there just be one? I have seen first hand two gateways that don’t talk to each other and then end users sometimes could connect to the Internet, and sometimes they could connect to internal stuff, but not at the same time! Doh!  Chris might be able to add more to this as I am not a networking guru, but I know it just isn’t right.

3) Data Warehousing – Now, The way SQL Server Analysis Services is set up, you have your SSAS server. Then you can make multiple "databases" under that instance. Sort of like regular SQL Server, Instance->Databases->Objects. The thing is, under an SSAS Database, you can create multiple cubes. Now, there might some small instances where you want to do this, but just because the GUI/API lets you create multiple cubes under a SSAS DB, doesn’t mean you should! For one, you can’t share linked objects between SSAS Databases, because both cubes are in the same DB. The other thing is that if both cubes are tightly bound or are mutually exclusive, then you run into MAJOR pains when trying to deploy/process, etc. You risk taking one cube offline because you are having a deployment issue with the other cube. Keep your cubes in separate SSAS databases! 🙂 I ran across this the other day which finally put the nail in the coffin on this issue for me

I am sure there are many more instances where there is the ability to configure or do something but you shouldn’t. It really can lead to major headaches and issues for all involved if common sense isn’t used beforehand. Although sometimes there is an unknown factor and you just have to decide, but then later when you realize it you should go back and fix it (that is probably a good topic for another post in itself!)

Keep geekin!