Recently I decided to change my whole network infrastructure. One part of this project was to replace my existing Windows machine, a Core i7 950 LGA 1366 based machine, with a new Core i7 3930K LGA 2011. Since enough things changed, I decided to sell my existing Windows machine and build a new one.

I did however decide to keep my Adaptec 3805 PCIe x4 RAID card that used to run in the existing Windows machine (3 x 1.5TB Seagate Barracuda 7200 rpm SATA II HDD's in RAID5, and 2 x 1TB Seagate Barracuda ES.2 7200 rpm SATA I hard drives in RAID1). I needed this space and since hard drives are so expensive with the floods in Thailand, it just made sense to keep it.

So on the new system I have this configuration:

One criteria is that whenever you listen to it you get an uncontrollable smile… This girl is awesome.

Even after many decades of the IT industry being around, there still seems to be a huge impedance mismatch between non technical people and technical people. I am not even talking about the split between the business and the IT department. Those are worlds apart. What I am referring to is the impedance mismatch between business analysts and system architects. Technically a business analyst is not necessarily a technology person, however business analysts working with software development teams are technology people - they need to be otherwise they cannot bridge the gap between the two worlds. They are called Technical Business Analysts or System Analysts.

So when a requirement from the business is analysed by the business analyst, and handed over to the system architect for estimation, even when it is just a high level estimate, sufficient details are required to enable such an estimate. The problem here is that the business analyst needs to understand enough of technology to provide sufficient information and to understand a very, very important aspect of system engineering. Many times the bulk of time and cost on a project is not spent on the easy, straight forward aspects. Many times the cost (and hence the reason so many projects overrun their budgets) are due to the exceptional conditions, the border cases that are extremely hard to work around and requires a huge amount of effort to implement.

So when a request is made for certain system changes, especially when those system changes consist of a myriad of potholes that will need to be navigated around, before an estimate of cost can be delivered at least some depth of analysis is required to understand the extent of these exceptions. I have built systems where the code for performing 98% of the system's operations were written in 30% of the time/budget, the final 2% took 70% to complete. Sometimes this is called the Pareto principle.

…is giving someone the ability to destroy you,

but trusting them not to.