http://www.codesweep.com/RssFeed.aspxThe life of the mild mannered codesweeper(c) 2008 Gregory Harris, code licensed under GPL V35<p>I really should try to write up my blog more than once a quarter, but I hardly ever think of anything good to cover, people want to help? Suggest stuff to write about and I might just go for it!</p> <p>Anyways today's subject, Code rewriting. If you're a fan of Joel Spolsky's work, he has railed against ground up rebuilding your product, but then reneged and said it can be a good idea under some circumstances. I tend to agree with this, but let me share with you a story of code rewrite gone wrong (note, names have been changed to protect the innocent).</p> <p>Right out of college I worked for a company called Data Storm. This company made a database product called E4. Which while a niche product had a few industries it was succesful in, mostly because it was really fast by most benchmarks, according to their statements, Oracle and SQL Server had nothing on them. Which may have been the truth from what I've seen. However this product ran in a dos command prompt and was getting a bit dated in features, look and feel. The time was coming to replace this product for the 21st century.</p> <p>So Data Storm gets together and decides to build a new product, we'll call it LionReason. This product was supposed to be the relational database killer, to put Oracle and SQL Server into their graves. Midway through the development of this product is when I joined Data Storm and got to see some of these events unfold.</p> <p>My job function at Data Storm was to do customer support for a few new extensions to allow Data Storm's E4 product to talk with Microsoft .NET products. However I had always been disappointed by the amount of support given to these extensions. These extensions at least allowed the old to talk to the new in some fashion. However only 3-4 engineers and 2 support personnel were allocated to this project at best. In fact this was a common theme at Data Storm, with maybe 5-6 engineers total working on Data Storms E4 products in general. The rest of the company's Research and Development were going to this Lion Reason product. </p> <p>In doing this the company was making a dangerous "Hail Mary" play. In that:</p> <ul> <li>They were betting, perhaps too hard that Lion Reason was going to succeed, it wasn't. <li>They were betting that legacy customers would hang on to their old systems until Lion Reason was ready, they didn't. In fact the common use for these .NET extensions were to enable a gateway to migrate to products like SQL Server. Ouch... </ul> <p>Needless to say at last look the company Data Storm is hovering at near bankruptcy now, with little hope of recovery unless some brilliant management takes the helm, which currently seems doubtful. However I still keep in touch with a few of my former co-workers at the company and have made some good friends there. Also this company launched me further into .NET and helped shape me into the consultant I am today. So I have much to thank Data Storm for...</p> <p>Moral of the story, it's fine to rewrite code from scratch, but remember the products that got you where you are...</p>http://www.codesweep.com/PostingDetail.aspx?PostingID=192Sun, 06 Jun 2010 10:13:00 GMT<p> So you're just breaking into the infrastructure world and now you're discovering the true meaning of a SLA. Your new client is telling you that we need "Four Nine's Reliability". Well great, but what does that mean exactly?</p> <p>First get over to <a href="http://www.netways.de/en/de/units/data_center/cluster/sla/">this website</a> and determine just how long your website can afford to be down. In this case you're allowed 5 ~minutes a month before you're in trouble.</p> <p> So great you tell yourself. You can do this, with 2 WFE's and 2 application servers in the backend with a SQL Cluster node, the odds of a failure knocking everything out are about a zillion to one right? (Note not actual numbers). </p> <p>Whoa...hold on there newb, you are not wise in the ways of SLA. Remember a few points.</p> <ul> <li>Virtual Machines, they've made it spectacularly easy for hardware to fail mulitple machines at once. Make damn sure your virtualized machines have some sort of backup capability in and of themselves. VMWare typically excels at this, and is my favorite tool for virtualizing environments, period...be wise in the way of the VMWare Server... <li>While the odds of a dual server failure are slim, ask yourself what are the odds of a total site failure? Think Earthquake's, Tornado's, Floods, etc. evaluate the environment your datacenter is in and start thinking about how fast you can recover from a site failure. I'll give you another hint, VMWare rocks here as well...but there are still some manual steps occasionally involved that may take you longer than 5 minutes...formulate your plans. </ul> <p>So don't just say 4 nine's reliability, MEAN it. Critical data is at stake here...</p> http://www.codesweep.com/PostingDetail.aspx?PostingID=193Sun, 11 Jul 2010 19:54:00 GMT