Landed (or stepped) in Linux - OpenSuSE 11.3 on my Alienware Area 51

I threw away Windows and loaded openSuSE 11.3 on one of my laptops (Alienware Area51 that I purchased in 2003).  Yes, you heard right, a 7 year old laptop.

Linux loaded fine, ran great, except for the WIRELESS support.  It took me a few nights of gcc compiling, kernel module loading and blacklisting, but I finally got the Ralink rt35xxsta driver working in OpenSuSE 11.3.  This was to get a non-supported Lynksys/Cisco AE1000 USB WiFi device working.  It seems to be OK, but every now and then it asks to re-associate with the AP.  And it asks for my root password when I boot.

But I am not complaining here.  Stories of Linux/Wireless woes are legion.  I am actually one of the lucky ones.

I am threw with Windows and PCs

Thank you Microsoft and Toshiba, I have finally seen the light.  In 2008, while working at Circuit City, just before it went belly-up, I mistakenly purchased a Toshiba Satellite.  I say it was a mistake because now only 2 years later, I have a door stop that used to be a laptop.  First the hard drive failed just after 2 years.  That is just unacceptable.  I have an Alienware that I purchased in 2003 that still screams.  I have a Dell that I bought in 2000 that still chugs along, albeit slowly (mostly a Windows pollution issue).  At the time I did not know that Satellite was Toshiba's code for poor quality.  Perhaps Toshiba is Japanese for crap.

I purchased a new hard drive and it took 4 hours to prep it after I installed it.  Then I tried to reload the Windoze P-OS and alas the CD ROM is now misbehaving.  That's for hours of my life that I will not get back.

While I was trying to fix the POSHITA laptop, I was also trying to download a 4.7 GB Suse Linux ISO image.  It is really not important what I was downloading except that it was Linux.  I am looking for an alternative to Win-blows.  I could not even attempt it with Microshaft's Internet Exploder, it doesn't handle files that large.  I had to use Firefox.  However, it kept locking up after about 2 GB.  So, I downloaded Google Chrome and it downloaded the ISO finally.  Three web browsers later, I then tried to write the image to a firewire DVD burner.  Alas, failed again.  Every time I would try to write the file, Windows would say that it could not continue.

I then tried to copy the image to a thumb drive.  However, Windows complained once more.  This time it said that the drive was full, when there was over 12 GB free space.  I was able to finally copy the files down individually.

This would be funny if it wasn't true.  Twenty years ago it was challenging trying to get PC hardware to work with the correct IRQ or even DOS.  Now, it is just annoying and costly.  PC manufacturers don't see their piss-poor quality as an issue because MacBook Pros are so expensive.  And most companies do not use MacBook Pros because they are so expensive.  However, I have never met an unhappy Mac owner.  Furthermore, the people in the Apple store just look happier.  I never saw that kind of happiness in CompUSA or Computer City (both of which are now defunct).

It is not just Mac; I have worked with Unix and Linux in the past, and lately (the last 4 weeks) I have been concentrating on Linux again.  If anyone spends anytime with that OS they realize how they have been lulled into believing that only Windows delivers value to organizations.  Microsoft has most of us, companies included, by the short-hairs.  Everyone wants productivity and most software runs on Windows.  It's the ultimate catch-22.

I really stepped in tech-sand this evening, like so many times before.  Again I was a victim of software and hardware vendors' planned obsolescence.  I see it as just another episode in series of minor Greek tragedies that I euphemistically refer to as PC repair.

IT Hero Worship is not a Successful Long Term Strategy

Are you an IT hero?  Have you ever worked late at night on an IT project (of any size) because you just did not have enough time during normal work hours to get it done?  Mind you, I am not saying that this type of hero is all good or all bad.  My biggest strength is “learner”; I love the idea of learning, even less than the end result of the knowledge gained.  That desire to learn has fueled many nights of heroism in the face of languishing projects.

The main issue I have with this type of hero is not the heroes themselves but how they are misused, and relied upon in many IT organizations today.  Just as hope is not a strategy, heroism should not be a strategy for making project deadlines.  In my experience most IT project failures are not technical in nature.  I have really never stopped a project because I could not accomplish something through software or hardware technology whose capabilities are fully understood.  However, I have witnessed how knowledge (or the lack thereof) and poor processes (or poor process execution) have stopped projects completely, or until new paths forward were found.

Process is the major culprit.  Under the umbrella of process I include project estimates, development methodologies, project management, and thought processes (for starters).  Of all of these, thought processes are the hardest to correct, and the most insidious.   For, it is here where the false paradigm of hero worship and reliance are engendered.

I submit that heroes are needed when we fail to execute.  I have lived this.  I have been pulled into projects midterm when the paths forward were clouded with process failure disguised as technology shortcomings.  Better processes would have led to better understanding of technology boundaries for a given solution.  This is actually where architecture improves the outcome, but that is a story for another time.

I am not saying that I have not fed off of this from time to time.  In fact it is somewhat addictive.  In the end, however, the repeated need for heroes inevitably leads to burn-out and morale issues.  It is not sustainable.  Examined from a business perspective, it leads to inefficiency and waste.  Perhaps this is what Russell Mullen and Steve Caudill discuss in their book “A Hero Behind Every Tree - The Non-Technical Reasons Your IT Investments Fail.”  I haven’t read it yet, but the title, description, and reviews seem to suggest the ideas that technology is not to blame for IT project issues or investment failures and heroes are not a strategy.  Even if I did not personally know the authors, I would recommend it for that alone.

Low Fidelity Prototyping and Plain English

When I was trying to cover Social Networking the other night in a business class lecture I tried to prepare for inevitable questions from students that had never seen some of these tools.  It was then that I literally stumbled across Wikis in Plain English.  Have you seen this Plain English series?  They are both entertaining and informative, which in my opinion makes them quite effective.

As I was watching the video on Wikis I immediately started drawing parallels between the Plain English series and Low Fidelity Prototyping (LFP), a.k.a. Paper Prototyping.  I used LFP to capture and present UI and workflow mock-ups quickly, in front of customers.  However, its intrinsic value in my opinion was realized in the information gained and relationships built by engaging the customers directly.   Everyone knows that not all customers are created equal and some customers find it difficult to contribute to project efforts, even though they are the single best resource for defining usability aspects.  In my opinion LFP is the simplest (not to mention inexpensive) and most effective way to get these customers to create with you.

After almost 20 years in IT I have trudged through many different movements in GUI and workflow design session tools and techniques:  JAD, RAD, Wire Frames, MS Visio.  However, LFP has always been the most flexible tool for quickly reaching customers and capturing the essence of their thoughts.  Of course once this information is captured it should then be distilled in to more readable models to ensure that manager types and end-users know that we as IT folks understand their world.

With the CommonCraft Plain English series here is an LFP in motion, with a twist of entertainment added.  If is very effective, conveying the intricacies of Social Networking tools, or even Borrowing Money.  In fact, I see the CommonCraft Plain English series as a aid to help us learn the effectiveness of LFP and how to use it to communicate with high fidelity.

Tech-sand vs. Technical Debt

In a recent conversation I was asked to explain the difference between what I call Tech-sand and what Ward Cunningham called Technical Debt. First, I do not see them as the same thing. In fact I see technical debt leading to tech-sand. The more technical or design debt that a business incurs, the harder it can be to get out of debt and move forward. The business is then stuck in tech-sand, not able to move forward, and not able to easily move back and undo what got them there in the first place. And don't even get me started on the irrelevance of considering sunk costs.

Yes some organizations plan for technical debt. In fact, I would argue that most organizations realistically have to absorb some amount of technical debt to remain proactive and competitive. Let's face it, IT is a commodity that is only differentiated by how well it is aligned with business and how well it is used to build barriers to erosion of competitive advantage. The idea behind knowingly incurring technical debt is to pay it down by incrementally replacing components or systems before "interest" payments (in the form of increased maintenance costs) become too large a part of yearly budgets or before aging systems are no longer nimble. Steve McConnell explains it well in his take on technical debt. I see it simply as how leveraged your organization is with technical debt. The more technical gearing you have the less efficient you are.

I argue that my term, Tech-sand, is broader in scope than software and hardware design and development. It is actually a worse case result. It can be the result of many different architecture and design decisions that are not well thought out, or based on politics or flawed financial models that do not understand the TEI (Total Economic Impact). Not understanding the true TCO of a solution can also lead to technical debt and and complete misunderstanding of what it means to service the technical debt.

Tech-sand can also be compared to a big ball of mud. However, again, it is not limited to strictly design and development of software or hardware.

The concepts of technical debt, servicing technical debt , and TEI should be looked at with the same rigor and systematic approaches that we use to judge the financial worthiness of companies. Apply the ratios. Today's IT budgets primarily go to operating expenses, easily 60% - 70% in some cases. How much technical debt does a company have and how much of their budget is used for operating?

How well a company manages IT and how well they make important technical and architecture decisions affect these operating budgets. Simply put, the more technical debt IT incurs, the more money in the operating budget it will need to service said debt. The trick here is to quantify this debt and monetize the budgetary aspects of its effects. Adding more people to the budgeted workforce to service a poorly designed or out of date system surely adds to the operating costs and can be seen as resulting from technical debt. Spending more every year, after factoring out customary software and hardware annual increases, points to a disturbing and identifiable trend. The IT department and more importantly the business is incurring technical debt faster than it can pay down the principle of said debt by replacing aging, poorly performing, and/or poorly designed systems.

Sooner or later these poorly performing, and myopic organizations will find themselves in Tech-sand. At that point, incremental steps are no longer adequate and major initiatives are needed.

Social Networking and Innovation

Is the use of Social Networking tools considered innovation? In an article I wrote several years ago, I defined innovation as "managing the processes that lead to the introduction of new
ideas, methods, and technologies that provide business value". While I am not sure that using Social Networking tools is innovation, using these tools can be innovative and lead to new ideas. In other words it can lead to or at least help innovation along. In an article I read by Jeffrey Phillips on the Innovation Tools web site, he declares that Social Networking is not innovation. Again, while I agree with most of his points, I think that Social Networking used correctly, including filtering noise, is invaluable to innovative teams.

If any thing, Social Networking is emerging technology if you consider as I do that emerging technology is technology that is not currently in use by a business. It's not just leading or bleeding edge stuff.

Lecturing on Social Networking

I am an adjunct professor at Strayer University. Lately I have been teaching a graduate-level business course (BUS508) and last night I gave a lecture on Social Networking. I focused on the tools, their utility, their potential business value, and how they could potentially disrupt business processes. Included in my talks were these tools and sites (I know there are more):

- Twitter
- Facebook
- Threaded Discussions (www.experts-exchange.com)
- OpenSpace
- Google Buzz
- Google Docs
- Google Reader
- Web blogs (blogs)
- Video Blogs (vlogs)
- Wikis (wiki-wiki, quick)
- Various Instant Messengers
- Usenet
- You Tube

The lecture was an instant success and it has actually turned into a graded essay assignment for my students. I used plenty of real-world examples including how my 10 year-old used Google Docs for his class assignment and then it with his class. I even tweeted about how I was teaching about Social Networking, sort of a circular reference.

The feedback that I received followed the same theme mostly; students were unaware of most of the tools. Of the tools that they did know about, considering their potential value or disruption to business was a new concept.