What Is the Bleeding Edge?

We had a fre­quent tech­no-geek debate around my ISP that came down to Bleeding Edge vs Stable.  But this argu­ment always assumed that there was only one bleed­ing edge. I believe there are two bleed­ing edges with a lot of room in the mid­dle. I am old enough to have used dou­ble-edged “safe­ty” razors and both edges are sharp and can cut deep.  Only by hold­ing it in the mid­dle can one not get cut (the so called safe­ty razor often induced cuts when I had to put a new blade in, bleh). When it comes to soft­ware ver­sions, one bleed­ing edge moves for­ward fast, only devel­op­ers and avid beta testers are actu­al­ly liv­ing there.  The rest of us are mere­ly try­ing to keep up, catch up, or we fall behind.  Those that fall too far behind are liv­ing on the oth­er bleed­ing edge, con­stant­ly deal­ing with the fact that they can’t do some­thing nifty keen new or get upgrad­ed because they are stay­ing “sta­ble”.  

So, what is the bleed­ing edge?  Instability, lack of sup­port, secu­ri­ty issues and the inabil­i­ty to change or change eas­i­ly are what I con­sid­er bleed­ing edge.  If you nev­er going to change and every­thing is work­ing per­fect, the bleed­ing edge is any­where but where you are at. Stability is your only cri­te­ria.  But if you plan on being organ­ic, have growth and rise to the chal­lenge of your needs and the needs of your clients —  the bleed­ing edge is always mov­ing, run­ning in front of you and wack­ing you in the rear if you don’t keep up. 

The basic sta­bil­i­ty debate can be seen in a large scale with the Linux dis­tri­b­u­tions.  One com­mon­ly rec­og­nized is between Debian and Ubuntu, a Debian vari­ant. Debian is the sta­ble plat­form. Ubuntu, well, it often imple­ments new­er soft­ware that takes a long time to get imple­ment­ed into the main trunk of Debian.   Ubuntu peo­ple have the lat­est and great­est but are accused of liv­ing on the “bleed­ing edge”. Debian peo­ple go for the tried and true claim­ing to be liv­ing “sta­ble” and with­out wor­ry but are accused of being left behind. For some, using Debian is the way to stay safe, for oth­ers, using the lat­est sta­ble ver­sion of Ubuntu is safe.

Fedora pro­vides an exam­ple of two bleed­ing edges.  Fedora releas­es a new ver­sion every 6–7 months.  Sometimes the new ver­sion is good and very lit­tle bleed­ing, oth­er times it is very bloody, Core 3 was an exam­ple of seri­ous bleed­ing, at least for me and release 8 seems to be giv­ing me prob­lems too. We are see­ing where the old­er releas­es are becom­ing the sec­ond bloody edge with sup­port for them being dropped by third par­ty ven­dors.   It isn’t bleed­ing because of sta­bil­i­ty issues, rather is is because of sup­port, some­times secu­ri­ty and usabil­i­ty issues, a soft­ware pack­age you need to use won’t work on the old­er releas­es any­more than it will work on the newest.

As of this writ­ing, Fedora is in release 8. It has had some good reviews. But for what­ev­er rea­son, it won’t install on my lap­top prop­er­ly, result­ing in blue screens. That makes it a bleed­ing edge for me but I am wor­ried that stay­ing with the ver­sion I cur­rent­ly have will even­tu­al­ly become a prob­lem for updates, the oth­er bleed­ing edge.  On the oth­er hand, my lap­top is get­ting long in the tooth so that the hard­ware bleed­ing edge may have caught up with me from behind and I can’t install ver­sion 8 because it is too old (?).

Lets take php as anoth­er exam­ple.  php5 has been released for almost 4 years now and php4 is being depre­ci­at­ed yet I know of one large com­pa­ny that still only uses php4 with no known test­ing or plans for migra­tion to ver­sion 5. Come on! They are con­tent with using only php 4 but they can­not take advan­tage of the capa­bil­i­ties of ver­sion 5 (like the OOP pro­gram­ming) and if they ever decide that they do need some­thing only avail­able in ver­sion 5 or the upcom­ing ver­sion 6, they aren’t ready to do so, which is going to make the tran­si­tion that much more dif­fi­cult.

Yes, there were some ini­tial pains asso­ci­at­ed with mov­ing to PHP5 but those pains get worse, not bet­ter the longer one waits to move on to what is not only sta­ble but rather old in soft­ware terms.  Try mov­ing a PHP3 site to PHP5 com­pared to PHP4 to PHP5 and one sees sig­nif­i­cant­ly more mod­i­fi­ca­tions need­ed to make it work, espe­cial­ly if the PHP5 site is using the now accept­ed set­tings com­pared to what PHP3 had. 

This is true of all soft­ware and hard­ware devel­op­ment! Waiting too long makes change that much more dif­fi­cult and painful! Waiting doesn’t reduce the pain, it often caus­es more!  

Of course, for exam­ple, if you wait­ed to PHP5 to start OOP code, you were bet­ter off in many ways but then I had made the deci­sion that php 4’s OOP was not worth imple­ment­ing so I didn’t get caught — it looked like a bleed­ing edge and it was.  But cer­tain­ly, decid­ing not to imple­ment some­thing sim­ply because, “It might not be sta­ble” is to invite the dou­ble-blad­ed razor to catch you any­way. 

To avoid get­ting cut, the solu­tion is some­what sim­ple real­ly and twofold.  Always have a test­ing plat­form to ver­i­fy the sta­bil­i­ty of new soft­ware — some­thing you should do no mat­ter what.  And always keep an eye on what is com­ing down the pipe in the way of new ver­sions of soft­ware and hard­ware you use.  You won’t get tak­en by sur­prise and  they can be test­ed on that test plat­form to deter­mine what new ben­e­fits they may pro­vide — you may dis­cov­er a new way to make mon­ey that you hadn’t thought of and would have nev­er know if you stayed com­fort­able in your “sta­ble” world.

Major tip: vir­tu­al­iza­tion is now mak­ing the cre­ation of mul­ti­ple test beds not only inex­pen­sive, but great for test­ing var­i­ous con­fig­u­ra­tions and soft­ware ver­sions on a sin­gle piece of hard­ware. If some­thing goes wonky, it is as sim­ple as throw­ing away that vir­tu­al instance.  

My test bed is an old AMD Athlon 2000+.  It works just fine for test­ing new ver­sions of soft­ware, estab­lish­ing new con­fig­u­ra­tions, and devel­op­ing new code before push­ing it to pro­duc­tion.  Since I use Gentoo for my serv­er dis­tro of Linux, I know that gen­er­al­ly they are con­cerned with sta­bil­i­ty and won’t always have the lat­est ver­sion of what I am using but I can test both their sta­ble ver­sion before push­ing it to my pro­duc­tion serv­er and if I desire, unmask one of the “unsta­ble” ver­sions to do some pre­lim­i­nary test­ing with­out wor­ry­ing about mess­ing up my “live” box. Also, since I trust the Gentoo guys, I will upgrade my pro­duc­tion box some­times with­out test­ing since gen­er­al­ly they have done all the test­ing for me — that is as far as I go liv­ing on the bleed­ing edge there.

If I start to think of adding new hard­ware to my pro­duc­tion box such as a new to me eth­er­net card or SATA card, I pop it into my test box and ver­i­fy it is com­plete­ly com­pat­i­ble with my soft­ware con­fig­u­ra­tion. Of course, if I could afford to have an iden­ti­cal box as my main serv­er as my test box, that would be ide­al, but the world isn’t ide­al and many times, adding hard­ware comes down to hav­ing the right dri­vers which can be test­ed.

Summary: sta­bil­i­ty is not the only cri­te­ria for not liv­ing on the bleed­ing edge and is often a poor excuse for not putting in some impor­tant work to keep a com­pa­ny mov­ing for­ward tech­no­log­i­cal­ly.  Stability as the only cri­te­ria will even­tu­al­ly lead to the oth­er bleed­ing edge, one that often costs a com­pa­ny more time and resources than if they would have kept their IT sys­tems up to date.

Leave a Reply