But now a problem has arisen with the Apple TV devices (I own two). Some weeks ago — I’m not sure exactly, since I have been traveling heavily since the start of November — my Apple TV(s) started dropping their wireless connection with my dual-band N router (DLink DIR-825, hardware version B1, firmware 2.06NA). Prior to that time, I could start streaming a playlist from one of our computers that have iTunes libraries, and the music would play for hours. Now it’s hard to get it to play for more than an hour the Apple TV drops, then reestablishes the wireless connection (halting the playlist in the meantime). Sometimes it will happen two or three times in the space of 5 minutes; other times, it will run for a few hours before resetting. But the problem itself and its variability makes the Apple TV fairly useless for streaming audio and video.

I did some of the usual — rebooted the entire wireless network, did a restore on the Apple TV, swapped the two Apple TV devices, made sure both had the latest software updates, and so on. Same problem. Searches on the ‘net showed that people have complained about similar or identical problems going back to 2010, but my problem didn’t start until about 6 weeks ago — my Apple TVs were pretty solid before then.

I ran a test earlier today which strongly suggests that the problem does lie with Apple TV. The living room Apple TV sits side-by-side with that Roku 2 device; both are hooked up to the same TV and are the same distance from the router (which, by the way, is only about 25-30′ away; most of that distance is open air, and there are no walls in-between). As it turns out, both the Apple TV and the Roku 2 support Netflix. So I fired up the Roku and picked a relatively short film to play (Blackadder’s A Christmas Carol). Said film played perfectly all the way through with no pauses, stutters, hiccups, or other issues. I then switched over to the Apple TV, brought up Netflix there, and selected the same film. It played fine for about the first 14 minutes — and then went into a pause mode (rotating circular arrow). Every few minutes, it would come out of that mode, play for another few seconds, then go back into pause mode again. This went on for a good half hour before I finally killed it.

I have yet another test running as I type this: I have both Apple TVs connected to the same router band (the same one the Roku is connected to), streaming audio from the same iTunes library (on this laptop) simultaneously. If one drops the wireless connection and the other doesn’t, then that increases the chances that it is in fact an Apple TV problem. So far, both are running fine (of course).

In the meantime, if others of you have encountered this problem and have known solutions, please let me know.  ..bruce..

Today, I bought a new (smaller) TV for our bedroom, replacing one that we have had for 8 or 9 years. On impulse, while picking out the TV at Costco, I also picked up a Roku 2 kit (Roku 2, HDMI cable, 2 month subscription to HuluPlus). I figured it would be interesting to see the comparison. Once home, I set up the new TV, hooked up the Roku 2 to it, and started the Roku 2 setup process. I got it talking to my in-home LAN (dual-band 802.11N router), and it signaled successful connection all the way out to the internet. It then told me that an update was available and gave me no other option than to download that update. Not a problem, I thought — always want the latest software.

Sigh. The Roku was never able to download the upgrade, and — this is critical — gave me no option to proceed to use the device without the upgrade. I made half a dozen attempts (all with the same failure, Code 011, unable to connect to Roku server), went to roku.com/support and had a nice chat with Jane, who suggested I reconfigure my router with explicit DNS addresses and then reboot my network. Did so — same problem.  She opined that the Roku server might be having troubles, or that it might be some other unspecified error.

Just to make sure there wasn’t some specific problem with the actual physical location of the Roku 2, I went out to the living room, unplugged my Apple TV, brought it into the bedroom, and plugged it in sitting right where the Roku 2 had been. Worked like a charm. I then went to Amazon and ordered a second Apple TV unit (scheduled to be delivered Saturday morning for just $3.99 in shipping, even though I ordered it Thursday evening — Amazon Prime is just brilliant).

I will probably hang onto the Roku 2 unit and in fact will likely connect it to the living room TV (along with the new Apple TV unit). Assuming that I can get it to update itself and let me use it, I’d like to see what it offers that’s different and/or better than Apple TV. But having had a fair amount of contact with Steve Jobs back during his NeXT days, I know that one of his product mantras was, “It just works.”

The Apple TV, like so many Apple consumer products, just works. And that’s why Apple wins.

[UPDATED 12/19/2011] Of course, having written that firm statement, I am now having problems with my Apple TV units. In the meantime, I did finally get the Roku 2 to register the day after I wrote this post, and it is working fine even though my Apple TV is not. Sigh…

I’ve written here before about the thermocline of truth. The webcomic Partially Clips gives a different, humorous slant; click on the comic to view it in full size. ..bruce..

This naturally intrigued me, since for the last 15 years, I have been writing, consulting, lecturing, and testifying about troubled and failed IT projects. While there are indeed tremendous financial losses due to late and failed IT projects, the figures Sessions gives seem much too large to me, and so I decided to do this critique of his analysis.

Sessions is good enough to provide the basis of his estimates and calculations, including footnotes. But that’s where some of the problems start. For example,  on page 3, Sessions cites (his footnote ’02′) to the US Budget, Fiscal Year 2009, Analytical Perspective (PDF), p. 169, for information on “at-risk” or failed IT projects, specifically:

• “According to the 2009 U.S. Budget [02], the failure rate is increasing at the rate of around 15% per year. If this trend continues, within another five years or so a total IT meltdown may be unavoidable.” (p. 3)
• “According to the 2009 U.S. Budget [02], 66% of all Federal IT dollars are invested in projects that are ‘at risk’. I assume this number is representative of the rest of the world.” (p. 3, in “Calculating the Cost of IT Failure” box)
• A large number of these ['at risk' projects] will eventually fail. I assume the failure of an ‘at risk’ project is between 50% and 80%. For this analysis, I’ll use the average: 65%.”

These three statements run into immediate problems. First, and relatively minor, Sessions gets his page number wrong: he’s citing “page 169″ of the Analytical Perspective document, but there is no discussion whatsoever on page 169 of that document about IT projects. However, page 157 of that document (which happens to be page 169 of the PDF document) does start a section titled “INTEGRATING SERVICES WITH INFORMATION TECHNOLOGY”, so I presume that Sessions made the simple mistake of using the PDF page count rather than the document’s actual page numbering.

Even so, serious problems remain with Sessions’ citations and analysis.

Page 157 of the Analytical Perspective document does not say what Sessions claimed in the two comments above. I have not been able to figure out where Sessions gets his figure for “the failure rate increasing around 15% per year” from the cited US Budget Analytical Perspective document, much less his conclusion that “if this trend continues, within another five years or so a total IT meltdown may be unavoidable.” As far as I can tell, the Analytical Perspective document does not talk about failed IT projects at all, much less the increase in failure rates.

Furthermore, the phrase “the failure rate increasing around 15% per year” is itself ambiguous and may not be that significant. To start with an arbitrary number, assume that 100 projects “fail” in a given year. If “the failure rate [is] increasing around 15% per year”, then that means that 115 projects would fail the next year, and 132 projects would fail the year after that. But unless we know both the actual number of failed IT projects and the total number of IT projects in that same year, Sessions’ figure tells us nothing. If there’s only 150 IT projects total, then the 15% failure rate increase becomes very significant; if there’s 1000 IT projects total, then we’re many years away from Sessions’ threatened “meltdown”.

Sessions also ignores or confuses the failure rate for new projects vs. the systems already deployed. In other words, the failure rate for new systems development says very little about the continued functionality of existing, deployed systems now in use. While there are occasions (most notably Y2k, now a decade behind us) where existing IT systems just won’t function or function properly if they aren’t fixed or replaced, by and large both governments and private concerns have gotten along remarkably well for years or even decades with antiquated systems

As for Sessions’ second statement, there is a table on page 158 that may represent the basis for it:

As can be seen in the FY 2009 column, 66% (535 out of 810) of the FY 2009 “Major IT Investments” are projects that are “Not Well Planned and Managed”. Note that this table does not (as Sessions infers) indicate Federal dollars but rather actual projects; that is, in FY 2009, there are 810 projects listed as “Major IT investments”, of which 535 are designated as “Not Well Planned and Managed”. The previous page appears to indicate that these projects represent $27 billion, which is roughly 38% of the proposed Federal IT budget — not a great figure, but still almost half of the 66% that Sessions claims.

What’s more, supplementary data (PDF) for the FY 2009 Analytical Perspective makes it clear that the US Government’s designation of such projects — which puts them on a “Management Watch List” (WML) — has reduced the risk of such projects during each fiscal year:

Note that in FY 2007 and 2008, the number of IT projects designated as “Not Well Planned and Managed” shrunk significantly during the year (from Q1 to Q4) without a proportional shrinkage of the overall number of major IT projects. In other word, it appears that the government’s efforts to remove such projects from the “Not Well Planned and Managed” category is relatively successful. And the actual US IT budget dollars at risk at the end of each of those fiscal years ($4.2 billion for FY 07, $8.6 billion for FY 08)  is a much smaller percentage (6.5% and 13%, respectively) of the Federal IT budget for each of those years ($64.2 billion for FY 07 (XLS), $66.4 billion for FY 08 (XLS)).

Sessions then states that “I assume this number [66% of all Federal IT dollars being at risk] is representative of the rest of the world.” There are numerous problems with this assumption, starting with the fact that the 66% figure is wrong; in fact, the actual “at risk” (his term, not the US Government’s) percentage of the IT budget at the end of FY 07 and FY 08 were, as noted above, 6.5% and 13%, respectively.

Sessions’ error here is significant, since he goes on in several places (cf. page 4) to cite his use of the % of the total IT budget as being significant, when he’s not talking about the total IT budget at all.

Furthermore, it is unclear whether his phrase “the rest of the world” means all other national governments, or all other entities doing IT project development. It seems to be the latter, though it’s hard to tell from his statements. On the other hand, I have spent years consulting with corporations on troubled projects, and I can tell you that they do not have 66% of their IT budgets devoted to “at risk” projects. In fact, the majority of corporate IT budgets are devoted to maintenance of existing systems, not new and risky projects (cf. here, here, here, and here, as simple examples).

As noted, Sessions then assumes that the failure rate for “at risk” IT projects is 65%, which means that (as he says) “I am calculating that 43% (.65 x .66) of the total IT budget” is devoted to failed projects. At this point, his figures become nonsensical, as they are derived both from misreadings and lack of complete information about the Federal IT budget and projects. To wit:

• The 535 “not well planned and managed” IT projects in the US FY 09 budget only represent 38% of the total IT budget, not 66% as Sessions mistakenly states.
• In the two previous years (FY 07 and FY 08), the number of IT projects labeled as “not well planned and managed” dropped during the course of each year (see the 2nd table above). In FY 07, it dropped from 263 projects in Q1 to just 84 in Q4, which means that 69% were moved off of the “not well planned and managed” list during the year. Likewise, in FY 08, it dropped from 346 projects in Q1 to 134 projects in Q4, a drop of 61%. This directly contradicts Sessions’ assumption of a 65% failure rate for projects in the “not well planned and managed” category.
• The FY ’09 Analytical Perspective says nothing about actual failed projects, as far as I can tell.

Sessions then goes on to make further out-of-his-hat assumptions regarding “direct and indirect costs”. He cites an example of the IRS (an agency long troubled by IT woes) and notes a lost opportunity based on fraudulent tax returns due to the system not being operational. He projects a loss over two years ($1.788 billion), compares it to the cost of the failed modernization ($185 million over a ten-year period), and calculates an indirect costs ratio of 9.6 to 1. He then decides — with no other documentation or analysis whatsoever — that the universal ratio of indirect to direct costs for a failed IT project ranges from 5:1 to 10:1, and uses the “average” of 7.5:1.

There are so many problems here that I scarce know where to start. For starters, the term “average” assumes an even distribution of ratios from 5:1 to 10:1 and does not recognize any ratios lower than 5:1. I’ve seen many failed projects that had much lower ratios of “indirect” to “direct” costs, since the firm simply continued to operate using the existing systems, and the “lost opportunity” for not having the new system in place was relatively small.

More importantly, the IRS gets to collect taxes from the entire US: $2.5 trillion in tax collections each year. Using the IRS as a baseline makes little sense for most other government agencies, and even less sense for most corporations and non-government organizations (NGOs), because most IT systems in most organizations (government or private) do not have the ability to generate such magnitudes of revenue, period.

Indeed, there is a long-standing controversy within IT management circles as to whether a new computer system can be relied upon to provide any significant return on investment (ROI), or whether it exists merely to “keep up with the competition”.

Sessions concludes his section on calculations thusly (p. 5, emphasis his):

Of course, these calculations are estimates. I recommend you don’t get overly focused on the exact amounts. I could be off by ten or twenty percent in either directions. The real point is not the exact numbers, but the magnitude of the numbers and the fact that the numbers are getting worse.

Unfortunately, Sessions is fundamentally wrong in his numerical analysis, and his numbers are off by far more than “ten or twenty percent”. For the Federal Government alone, they are off by almost  a full order of magnitude (10x), due to his critical errors both on the percentage of the Federal IT ’09 budget “at risk” (it’s 38%, not 66%) and the number of “at risk” projects that fail (he says 65%; the US government numbers for FY 07 and 08 show that only 35% of the projects — representing just 6.5% to 13% percent of the Federal IT budget — were still “at risk” at the end of each fiscal year, and it gives no figures that I can find for actual failed IT projects).

Furthermore, his projection of the (erroneous) 66%-of-IT-budget-at-risk figure on the rest of the world is just wrong, especially in corporations and business (which spend vastly more on IT than the US government). In those organizations, maintenance costs dominates, and the percentage of the IT budget devoted to new projects tends to be small (20% or less), with an even smaller fraction of that representing “at risk” projects.

I may comment more on Sessions’ paper, but my conclusion here is that his estimate of $500 billion/month in lost direct and indirect costs due to IT systems failure just does not hold up, in my opinion.  ..bruce..

Over the last forty years, a small set of classic works on risks and pitfalls in software engineering and IT project management have been published and remained in print. The authors are well known, or should be: Gerry Weinberg, Fred Brooks, Ed Yourdon, Capers Jones, Stephen Flowers, Robert Glass, Tom DeMarco, Tim Lister, Steve McConnell, Steve Maguire, and so on. These books all focus largely on projects where actual software development is going on. A new book by Phil Simon, Why New Systems Fail, is likewise a risks-and-pitfalls book, but Simon covers largely uncharted territory for the genre: selection and implementation of enterprise-level, customizable, off-the-shelf (COTS) software packages, such as accounting systems, human resource systems, and enterprise resource planning (ERP) software. As such, Simon’s book is not only useful, it is important.

Go read the whole thing. ..bruce..

It is now 2009. Individuals primarily use portable computers, which have become dramatically lighter and thinner than the notebook computers of ten years earlier. Personal computers are available in a wide range of sizes and shapes, and are commonly embedded in clothing and jewelry such as wristwatches, rings, earrings, and other body ornaments. Computers with a high-resolution visual interface range from rings and pins and credit cards up to the size of a thin book.

People typically have at least a dozen computers on and around their bodies, which are networked using “body LANs” (local area networks).1 These computers provide communication facilities similar to cellular phones, pagers, and web surfers, monitor body functions, provide automated identity (to conduct financial transactions and allow entry into secure areas), provide directions for navigation, and a variety of other services.

For the most part, these truly personal computers have no moving parts. Memory is completely electronic, and most portable computers do not have keyboards. . . .

The majority of text is created using continuous speech recognition (CSR) dictation software, but keyboards are still used. CSR is very accurate, far more so than the human transcriptionists who were used up until a few years ago.

Also ubiquitous are language user interfaces (LUIs), which combine CSR and natural language understanding. For routine matters, such as simple business transactions and information inquiries, LUIs are quite responsive and precise. They tend to be narrowly focused, however, on specific types of tasks. LUIs are frequently combined with animated personalities. Interacting with an animated personality to conduct a purchase or make a reservation is like talking to a person using videoconferencing, except that the person is simulated.

Computer displays have all the display qualities of paper–high resolution, high contrast, large viewing angle, and no flicker. Books, magazines, and newspapers are now routinely read on displays that are the size of, well, small books.

Computer displays built into eyeglasses are also used. These specialized glasses allow users to see the normal visual environment, while creating a virtual image that appears to hover in front of the viewer. The virtual images are created by a tiny laser built into the glasses that projects the images directly onto the user’s retinas.3

Computers routinely include moving picture image cameras and are able to reliably identify their owners from their faces.

In terms of circuitry, three-dimensional chips are commonly used, and there is a transition taking place from the older, single-layer chips.

Sound producing speakers are being replaced with very small chip-based devices that can place high resolution sound anywhere in three-dimensional space. This technology is based on creating audible frequency sounds from the spectrum created by the interaction of very high frequency tones. As a result, very small speakers can create very robust three-dimensional sound.

A $1,000 personal computer (in 1999 dollars) can perform about a trillion calculations per second.4 Supercomputers match at least the hardware capacity of the human brain–20 million billion calculations per second.5 Unused computes on the Internet are being harvested, creating virtual parallel supercomputers with human brain hardware capacity.

Be sure to read the entire chapter. There are some predictions he gets right, but in most cases, he overshoots what is actual with what is theoretically possible. It’s a bit like predicting that all VCR machines would vanish a year or two after DVDs became available (in reality, the demise of VHS took about a decade).  Also, as some of the comments to this online version of the 2009 chapter point out, several key predictions depend upon significant advances in artificial intelligence (AI), and those advances just haven’t happened.

In fact, one of the commenters has a wonderful observation: “The non-Mooresian nature of AI, and software in general, is the big problem here.” Moore’s Law, of course, was cited to predict increasing densities of transistors on integrated circuits and has been extended to the general (and decades-long) trend towards cheaper, faster, more capable computer hardware. The problem is that software doesn’t respond to Moore’s Law. Advances in software actually tend to face diminishing returns (cf. Microsoft Vista), not exponential improvements.

In fairness, I note that I once made a decade-in-advance prediction. But in my case, I largely constrained myself to computer hardware and just did a straight-line extrapolation. In my book Pitfalls of Object-Oriented Development (M&T Books, 1995), I talked about the changes between developing software in 1984 and 1994, then predicted what hardware might be like in 2004:

A case in point: In March 1984, Wayne Holder and I shipped SunDog: Frozen Legacy, a complex, real-time adventure game for the Apple II, which had a 1-MHz, 8-bit 6502 processor. With its graphical user interface using overlapping windows, icons, menus, and joystick-only input, SunDog pretty much pushed the limits of the Apple II. It required 64-KB of RAM and even then swapped segments of code into memory on demand. We used a double-sided floppy disk, giving us 280-KB of disk storage. Code size: 15,000 lines of Pascal and 5,000 lines of 6502 assembly language. I was the principal programmer, writing more than 90 percent of the code; from inception to shipment, the project took 15 months.

Ten years later to the month—March 1994—Pages Software, Inc. shipped Pages by Pages, the document processor mentioned at the start of this introduction. Pages runs under NEXTSTEP 3.0 or later; typical system requirements are a 25-MHz 68040, 33-MHz 80486, or HP-PA RISC system, all 32-bit processors. The application assumes virtual memory (which NEXTSTEP provides), but it is recommended that users have at least 16-MB of memory and 20 MB free on a 300- to 500-MB hard disk drive. Code size: 350,000 lines of Objective-C, which doesn’t count all the graphical user interface support provided automatically by NEXTSTEP’s class libraries. The engineering team grew to encompass ten people, and the product shipped nearly four years after Pages Software was founded.

Imagine what desktop systems and user expectations and operating system requirements will be like in March 2004. Straight-line extrapolation says we’re looking at 500-MHz systems with 1 to 4 gigabytes (GB) of RAM and a 20- to 100-GB hard disk drive. Common sense may make you question those figures—after all, how could anyone ever use up 100 GB of disk space?—but I use 1 GB right now and have a constant need for more space.

If anything, I was too conservative — such is Moore’s Law. I have a PC in my office that has a total of 1.5 terabytes of storage hooked up directly to it (either internal or directly connected via USB) and has another 1 TB of storage sitting on the network.

My intent is not to criticize Kurzweil; it’s to point out how hard it is to predict technological advances. Be sure to read his entire chapter.  ..bruce..

Here are what I see as being some of the core classic problems with a system such as this.

The “No Room for the Infrastructure” problem. While the elevated tracks are vastly cheaper and easier to construct than, say, corresponding subway tunnels, they still require above-ground space and a regular footprint at ground level. Most existing urban and even suburban areas simply don’t have the room available, either in the air or above the ground. The political and economic costs of purchasing such room (via eminent domain and other takings) would be prohibitive in most urban/suburban settings.  And while everything in the video looks clean, light, and airy, you simply need to spend a little time around most mass-transit stations to see how they act as magnets for vandalism, graffiti, and litter.

The Last Mile problem. Because of the room problem above, the ULTra network would not likely achieve much network density except in limited and constrained locations (such as an airport or a newly-constructed office park). In actual urban/suburban settings, ULTra would likely end up having a sparse network feeding into existing mass transit systems (subway, buses) or leaving you to walk the rest of the way. As such, it is unlikely to reduce car usage.

The Pay As You Go problem. Mass-transit systems are notorious money pits, heavily subsidized via unrelated taxes and federal subsidies (but I repeat myself), since actual rider fees are not enough to pay for the system’s on-going operations, much less the original cost of construction. My wife and I lived in the DC area for a total of nearly 8 years (six of which were in the District itself), and I was a great fan (and heavy user) of the DC Metro subways. But WMATA is always struggling financially, and that’s true of most mass transit systems. Here in Colorado, where we’ve lived for the last 3 1/2 years, the Denver Light Rail system found itself looking at cutting back services this year — due to reduced sales tax collections and higher fuel costs — even as rider volume was going up as gas prices passed $4/gallon.

The Hidden Costs problem. Somehow, much of the public discourse over (electric) mass transit assumes or implies that electricity is free, or at least carbon neutral. It’s neither. Most electrical generation in the United States comes from burning hydrocarbon-based fuels: coal, natural gas, and a bit of oil. And even if the electricity comes from wind, water, geothermal, solar or (my favorite) nuclear, it still costs money and it still has a carbon footprint.

The Scalability problem. Paul Raven, who blogged about ULTra over at Futurismic, raised this issue himself. The ULTra system shown in the video relies on relatively small cars — four seats each, with some standing/storage room between them — that are spaced apart by the controlling software. Assuming a spacing of 3 seconds between cars, that sets an upper limit of moving 4800 people/hour. This is better than, say, busses on a given route, but it’s less clear how competitive it is over existing train, light rail and subways systems, and it doesn’t begin to approach what the automotive infrastructure can carry.

The Coordination problem. One of the long-standing complaints about the automotive system is its high inefficiency, that is, you have millions of cars on the road, the overwhelming majority of which are carrying one or maybe two individuals. ULTra, by being demand-based, sets itself up for the same problem. If I read the video and website correctly, I can walk up and select an unused ULTra car, punching in my desired stop, and go straight there. By so doing, I may tie up an ULTra car all by myself, going from Point A to Point B. This reduces the overall capacity and efficiency of the system; to overcome that, I must then choose to announce my destination, interact with others (“Who else in going to [Destination X]?”), and decide who else I want getting into that rather small car with me. This leads to…

The Safety problem. Personal safety on mass transit is usually provided by the presence of other people; that is, you are less likely to be mugged or assaulted on a crowded subway car or bus due to the presence of all the other people around you. (Hence the classic drama/horror trope of being on a subway car with just one other, sinister-looking person on it.) Should I let another person into my ULTra car, presumably because that person is going to the same destination, I am then trapped alone with that person in that car all the way to that destination. I suspect there will be a “let me off at the next possible stop” button in the car, but that may not be enough. Likewise, there will likely be an inboard camera, but a second or two of spray paint will take car of that. On a less dramatic note, vandalism of the interior of the cars themselves will likely be increased  for that same reason of isolation (no one around to see what you do to the car).

OK, that’s what I came up with on the top of my head. Can you think of others, or do you have counter-arguments to what I’ve listed above?

Again, I’m a great fan of usable mass transit systems. When I lived in Washington DC, I regularly went to New York City on business without once climbing into a car or a plane; I’d walk down to the nearest Metro stop (Cleveland Park, Red Line), take the subway to Union Station, take an Amtrak train to Penn Station in NYC, then walk crosstown to my hotel or business destination. I’d then reverse the whole process to go home again. But I was also quite aware all that time of the financial struggles and subsidies of both WMATA and Amtrak.

Likewise, ULTra will only succeed in small, constrained settings, such as airports and office parks. The video itself references those two settings, but the ULTra website references grander uses. I just don’t think they’ll happen, at least not without massive government spending, and even then they won’t make a real impact in automotive use.

As always, your mileage may vary.  ..bruce..

And if you have read them, you should probably re-read them.  ..bruce..

My two latest Baseline columns talk about ways to retain IT staff. The first column talks about making an effort to align your staff’s individual professional goals with your organization’s goals. The second column talks about how to improve your IT staff while encouraging them to stay with your firm.

As always, feedback is welcome here or there.  ..bruce..

The first column, “Second Class Software Quality for Major IT Projects”, talks about the curious fact that organizations are willing to spend millions, tens of millions, even hundred of millions of dollars on major IT project and yet still nickle-and-dime their software quality assurance (SQA) effort. It doesn’t help that SQA personnel are pretty much on the bottom of the tech status totem pole, either.

The second column, “Do Not Defer The Difficult in IT Projects”, describes the all-too-human tendency in IT development to put off dealing with the toughest problems until last — at which point, you may not be able to solve them all. It also explains why so many IT projects get 80-90% “done” and then suddenly slip for weeks or months without making much progress.

Enjoy, vote, and comment!  ..bruce..