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.

Mapping Agile Success

So, I am wondering if Agile successful adoption levels have been mapped. When I say mapped, I mean mapped in two dimensions, Value Stream Mapping and Momentum Mapping (R. Ryan Nelson and Karen J. Jansen (University of Virginia) MIS Quarterly Executive – September 2009).

I am not a Lean expert, but from what I know, delivering projects via waterfall creates waste, mainly due to "partial work done." Delivering incremental value reduces waste, but by how much? Can this be mapped?

VSM (Coarse-grained)
1. First, VSM the the current waterfall delivery processes, indicating waste points.
2. Next, over time, adopt an Agile methodology.
3. Finally, re-map your delivery methodology under the new Agile processes. Shouldn't the second VSM now show less waste?

Perhaps this is a good place to start: The Art of Lean Software Development: A Practical and Incremental Approach

Granted this is a contrived example, but if Agile delivers value incrementally, before and after VSMs should be able to show the decrease in waste and increase in value.

Understanding value streams is all fine and good, but to me Agile is also very dependent on the team positivity or negativity. How they perceived the progress of the sprint or project can drive how they are open to adopting or adapting to Agile. Emotional Seismographs (Esther Derby) can be used to map "...how people responded to events....and provides clues on where the real juice is for a particular project community..." These seismographs are also know as Momentum Maps.

So between the two mapping methods, we can get an reading on waste-removal and value-added as well as how well our teams are adjusting and implementing Agile.

There is more to come on this topic as I work through the mechanics of these two techniques.

XSS Restrictions - A barrier to UX and eloquent design

So, this is sort of a rant, but here goes. I am working on an E-Commerce punch-out application. For the uninitiated, punch-out is a form of E-commerce where by the user of a procurement system wants to shop for items found in a remote inventory management Internet site. The user initiates an action in their system that "punches-out" of their system and into a shopping experience hosted by the remote system. The user shops in the remote system and then returns their local system with the shopping cart contents, including pricing. Punch-out is based in large part of the CXML standard. It is CXML that is exchanged in these punch-out conversations between each system.

To test our new system, I wrote a small Java web app that uses AJAX to send and receive the CXML to the remote system. Since AJAX using JavaScript, I immediately ran into security issues with XSS (Cross-site-scripting). I know about XSS, but I initially ignored it because this test app is an Intranet only app running on my local Tomcat server. I was wrong to be so cavalier.

I am using IE8, and IE8 (along with other modern browsers) has seen fit to disable XSS by default. After all, XSS is a major security issue. I just don't think that it is a major security issue in my environment and I resent the fact that I can not use it. So I did some digging and it just so happens that I can disable the XSS Filter in IE8 by passing the proper HTTP response header to the web browser, from my Tomcat sever.

response.setHeader("X-XSS-Protection","0");

This code will stop IE8 from preventing the potentially malicious AJAX call and simply alert the browser user of its existence. However, if I try to use SSL then I am right back to where I started as IE8 just seems to ignore my response header in this situation. So, now my AJAX is muted.

I saw AJAX and AJAX-like technologies to be a major positivity to UX (user experience) design in modern web applications. However, unless I am satisfied to only make AJAX calls to my local server, I am doomed.