Too much innovation or too little talent?

Too much innovation or too little talent?

Summary: Nicholas Carr of "IT Doesn't Matter" and Does IT Matter?

TOPICS: Tech Industry

fbiNicholas Carr of "IT Doesn't Matter" and Does IT Matter? fame writes in a New York Times op-ed piece about the FBI's software train wreck-- the aborted

Topic: Tech Industry

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • People Just Don't Know Software

    The problem is that management becomes management not by knowing how to build good software, but because they know somebody, or they are good at B.S., or they're the default choice.

    Instead of practicing good software design and engineering, they approach it from a business perspective -- throw n number of engineers at it and it should work, right?

    They have no idea how to create good software, what it takes to run a development project, so everything goes down the tubes.

    Whatever. Corporations stupid enough to hire these companies deserve what they get.
    • you may be right

      Software is getting increasingly more complex to make. Humans ability to handle the multifaceted integration of software has become a difficult task. Bottom line for business - get the job done well enough to be acceptable is all that is required.
      Good software development comes down to this; knowing your product and asking through every step of development 'what if' and then making appropriate moves to fix what is necessary for function and compatibility. Deficiencies result from lack of adequate communication to slothfulness in addressing the 'what if'.
      The issue with using newer more complex software falls along similar lines and implementation requires a more gradual "evolutionary" approach to smooth and accepted integration.
      • Customers are tolerent of IT--so far

        There may be a problem of class P with a distinct software buyer B and a software developer D but even when B and D are both members of the same elite class of software developers, they end up having problems of class S P a super class of P (having a wider range of more general problems).

        With all the SWE Methodologies, Metrics, CMM Level 5, ISO 9000:2000 +++ there seems to be no reliable and repeatable way of developing and delivering software within bounded parameters.

        That is the real problem and IT alone has to solve it for its own sake.

        Customers and Governments have been very generous with IT Industry and they are still paying for IT but that will not be for long.

        What IT would not do professionally may be forced legally?hope not retrospectively!

        Putcha V. Narasimham
  • From Nick Carr

    Dan's right to emphasize the importance of solid managerial and
    technical skills in carrying out a complex software project (or
    any complex project, for that matter). In particular, I'm
    convinced that many big IT initiatives are doomed by mediocre,
    or nonexistent, project management skills. Not only does weak
    project management lower the odds of success, but it raises the
    odds that initial budget and schedule expectations will be way
    off the mark. But an organization needs more than the right
    talent; it needs the right perspective, the right approach and the
    right set of assumptions. My argument is that organizations,
    facing the need to automate a particular process, should first try
    to copy, borrow, buy or steal the software they need, and they
    should be willing to consider rejiggering their processes (or their
    goals) if necessary to accomodate an off-the-shelf or otherwise
    proven solution; only after they've ruled out those avenues
    should they proceed down the exceedingly risky path of creating
    a big new system. As I put it in the New York Times article,
    "innovation should be a last resort, not a first instinct." That
    doesn't mean you should never write custom software; it just
    means you should be damn sure that simpler alternatives aren't
    available. The FBI, given a more or less blank check by Congress,
    seems to have rushed to invent its own program for tracking bad
    guys. Now, it's $170 million in the hole with nothing to show for
    it. No doubt the FBI has some nonstandard requirements, but its
    basic goal - a database that can securely provide up-to-date
    info to a disbursed set of people - isn't exactly breaking new
    ground in the world of software design. Indeed, one wonders
    whether very similar systems haven't already been created by
    law-enforcement or other agenices within the federal
    government. Has the government thought about setting up a
    software-sharing consortium among its agencies, aimed at
    cataloguing existing software and promulgating its reuse (or at
    least spreading best practices related to its creation)? The fact is
    that most processes, in business and government, have already
    been automated, and some of the existing solutions actually
    work quite well. A rush to innovate is a rush to fail.
    • COTS software

      In my experience COTS applications (to be distinguished from COTS operating systems, DBMSes, application servers, component libraries, etc) are less effective, more costly, and less stable than in-house developed applications - provided you have a development staff that is both large enough and skilled enough.

      For example, one project I worked on was attempting to use COTS software to perform an analysis with rather straightforward requirements. It's been 6 years now, and the COTS vendor has yet to produce the capabilities it originally promised.

      On the other hand, I'm about to wrap-up another project that performs a similar but significantly more complex form of analysis. In the end the project will have taken ~16 months, will have cost a small fraction of what the previously mentioned application cost, and WILL ACTUALLY WORK.

      As a side note, I should mention the second project does leverage significant COTS software. The application runs on the .NET framework and stores its data in an Oracle database running on a Unix box. But that's an entirely different class of COTS software.

      As for the argument that the business should adopt the processes defined in the software rather than customizing the software, I think that is horridly wrong. If a SOFTWARE VENDOR can define more efficient processes YOUR BUSINESS than either (a) you are horribly inefficient and are doomed to fail, or (b) you should be outsourcing those processes because they are outside your core competencies and cannot differentiate you from your competition.

      In my opinion, the mantra "adapt your processes to the off-the-shelf software" is the direct result of software vendors consistently pushing unextensible vaporware that corporate IT can't make meet the business's needs - so they tell the business what its needs are.

      In regards fighting the urge to innovate, I completely agree. There's usually so much low hanging fruit for processes to automate, or for improving existing automation, that there's little need to tread new ground. Of course, innovation is easier to sell. How do you quantify the savings of reducing the number of clicks it takes to perform a task? Or eliminating the need to scroll on a screen? Delivering error messages that ACTUALLY MAKE SENSE?
    • Nick's response

      Nick and I agree...I emphasized the people problem...he is talking about the lack of pragmatism and focusing on solutions that are less innovative but more realizable, rather than striking on uncharted waters...which should be avoided if possible. However, it turns out that the failings or discoveries of those venturing in uncharted waters form the foundation of more civilized and less risky just don't to be one the spending millions in cost overruns and time lost to innovate for others...
      • Lack of Talent

        If an organization lacks the talent to pull off a large-scale (or even small scale) IT project, its IT projects will be doomed to fail, regardless of whether they are innovative or not.

        The single most important aspect of IT program management is to win and maintain the buy-in of all the stakeholders. This includes everyone from executive sponsors to end-users and individual programmers.

        This means that the program manager must be constantly "selling" the program, and presents four challenges. The first is avoiding over-promising. People are almost always more eager, at least during initial planning, to buy into something that sounds revolutionary. The second is managing to deliver what was promised. The third is that while it's easy to get people excited about future revolutionary changes, it's hard to get them to accept them once they are a reality. The fourth, and real kicker, is that if you promise enough to get initial buy in, and then deliver at the level that the organization is prepared to accept, the organization will reject it because it's not what they were promised.

        That means that the program manager (or, rather the program manager's staff, the PMs aren't actually supposed to do or know anything, because if they do they represent a single point of failure within the program) must find the perfect level where the organization's eyes for innovation match its stomach for real change.
    • Not COTS, GOTS

      Government doesn't use COTS software, they use GOTS software government of the shelf :).

      I work for a small-to-middle sized beltway bandit type consulting gig and we make our bread-and-butter business by implementing the same procurement package (custom tweaked for the customer by a sub to us) wrapped or bolstered by our custom code around it to meet any process differences the specific agency might have.

      I think the problem here is project management and not knowing what you're trying to do - there's probably any number of COTS things that'd get the FBI 75% of the way (lots of ECM packages would probably do that for them) and then you just need someone with the vision and guts to implement a workable solution that meets their requirements in a flexible enough fashion.

      I mean, call me crazy, but who in the world would design an application for the FBI that only worked on certain types of crime? sheez!

      They should hire me, I could atleast design them an app around a decent ECM package that'd get the job done and be flexible enough to allow adding new modules with relative ease - especially given the power of both Oracle and SQL Server to allow me to implement XML objects right in the database and query them to get data back.


      (hubris anybody? lol)
    • time to put up or shut up?

      Mr. Carr writes,

      [i] "My argument is that organizations, facing the need to automate a particular process, should first try to copy, borrow, buy or steal the software they need, and they should be willing to consider rejiggering their processes (or their goals) if necessary to accomodate an off-the-shelf or otherwise proven solution; only after they've ruled out those avenues should they proceed down the exceedingly risky path of creating a big new system." [/i]

      Having read this point in numerous commentaries by Mr. Carr, I would observe that the horse he's beating is most thoroughly necrotic now.

      While some portion of failed IT projects fail because the concept was flawed, in my opinion [b] more fail because of management issues [/b] - poor project management, failure to get buy-in at the right level of the organization, cost overruns, and staff turnover. I suspect that all of the above was true in the case of the FBI project.

      Still, let's suppose Mr. Carr is right. I think [b] he could do the country a great service by simply pointing out to the FBI where they could obtain existing software [/b] that merges the databases of dozens of other investigative organizations, that provides an intuitive and comprehensive search interface, can be updated in real time by field agents, and will at the same time protect the rights and privacy of American citizens. I'll make his job easier by pointing out that I've seen the software - it's in use on the set of CSI, and bears every resemblance to real modern-day software that Star Trek does to the NASA shuttle program.

      [b] Meanwhile, I'll keep an eye out on eBay. [/b] Maybe some used piece of off the shelf, turnkey software will turn up there and I can convince the FBI to snap it up before some other lucky law enforcement agency spots it.

      In closing I would like to offer my congratulations to Mr. Carr for managing to get even more mileage out of his fatally flawed thesis. [b] As long as reporters keep calling, eh? [/b]
    • Business already mistrusts us but must shoulder some responsibility

      While I agree with some of the principles of Nick's assessments in all his writings - he seems to put much of the blame squarely on IT staff who love to play with new technology or show how intelligent they are when designing new solutions. I am a believer in simplest method as well - but from my experience it's been that the distrust from IT to run projects has already been part of the process - and hence part of the problem.

      Business units without the ability to understand what is currently available or how long it takes tend to create project plans and at the last month before product delivery ask IT to do the creation. This completely ignores many IT security and operational policies to ensure that solutions are up and running 7x24 and don't allow hackers to get in. This perpetuates the bad blood since the lines of business believe IT is simply not interested in the business success. Of course the argument is turned completely around when something is deployed quickly to meet a marketing deadline and then crashes - again, IT's fault somehow...

      I believe another major issue is that the business tends to want new solutions - but in the design and requirements phase no one is willing to break processes that are poor performers. Everyone wants their little part included - which essentially means designing new software to replicate what you already have. IT should be looked at to assist with proper requirements and goals - and the business should be willing to be told "no, you can't have everything in the toy bin - just what you really need"
  • FBI

    While I have little experience with the FBI, I've often been amazed at the extent to which the National Labs will build their own instead of buying commodity technology. One might try to argue that proprietery technology improving security. A potiental spy will have a more difficult time exploiting a tool with which he has no knowledge. However, I think it's just the IT guys creating work for themlves to improve their funding.

    As to the so called "failed" FBI project. It could very well have been reclassified and packaged under a different name. I don't know why it wasn't classified to begin with. You don't very well want terrorist knowing what systems are tracking them.

    I'm sure that well over 90 percent of fundamental research projects fail to produce something useful. IT research should be no different so I find your quoted success rates phenomenally successful.
  • Government and IT Don't mix

    Back in the late eighties our purchasing and requisition process barely, or didn?t, act quickly enough to keep up with technology. IT projects, especially software products, should not ever be thought of as an IT decision. The other CxO?s need to evaluate these plans so they know what the first, second and third phases will produce as a result of each phase. I personally know hundreds of individual, independent, coders who could have completed the FBI project on time and WELL within the budget. Problem is most of them don?t have the time to tackle such a big project as they are entrepreneurs and trying to build a company and just don?t have time to spend three months planning for a project of this nature. There are 500 of them who frequent the New Millennium Minds blog.

    We need to reinvent how the government interacts with IT firms, coders, etc.
  • Each Issue Was A Problem

    My experience has been that you should only develop a new product if you really, really need customization or features that are not available in existing commercial products, especially when you are considering developing a product that you could not sell to other organizations. The argument should start in favor of purchasing a product and it should be the job of those who support developing a new product to convince everyone to change their minds. Look at the Carnivore failure. They spent a bunch of time and money developing this special system all their own, and ended up scrapping it shortly after in favor of an off-the-shelf product. Of course, they didn't admit it until recently when the story broke.

    I think that turnover has a lot to do with their problems as well. I know a number of people that work in the government, and the ones in IT say that they're only going to stay there until they can get a job in industry that pays much better. Benefits with the governement are good, pay is bad. I think the average time an IT worker stays with the FBI is now under two years. It's pretty hard to get a project going well when you have that kind of turnover rate throughout your entire IT department. Maybe if Congress paid themselves less anf the governement wasted less money on failed projects, they could afford to keep their talent.

  • FBI software: not a new problem

    Software development problems at the FBI are nothing new. When I ran a software company in the late 1980's and early 1990's, they had many of the same problems as they are having now. You can't build a good software system if you can't accurately define the requirements for the system in the first place. The Feebs thought that they had top people doing their work, but I never found that to be true. If they were a football team, they would be 2-14.
  • FBI Software Disaster

    IT disasters always start with poor communication. Users have a poor grasp on what automation can and cannot achieve. Users also think IT can automate a brand new process that was never done manually.

    Then the hardware/software gurus, eager to get the contract, over-promise what they can deliver (leading to cost overruns and delays in production).

    Most databases are predicable, boring affairs - not glitzy, instant gratification systems (like the magic software featured on CSI and NCIS episodes).

    Consider the black eye the FBI got over the terrorists learning to fly at US schools. There was no reliable, manual mechanism in place to deal seriously with reports from one female FBI agent (Coleen Rowley). Automating her concerns would have just thrust her e-mail into a void, where, like a desert bloom, it would be "born to blush unseen, and waste its sweetness on the desert air." (Thomas Grey 1716-1771)
  • Google it!

    Seems silly to say now as a "monday morning quarterback", but considering the technology Google is introducing week afer week... a simple multi-dimensional database such as U2/Universe/D3 and a document storage system that could be Googled and a very simple "coding" system to file the documents would have done just fine.

    But then again, not enough money in it for the guvmint! Must not be any good.
  • The approach was fundamentally flawed

    I posted about this in my post "Advice to FBI: think small"
  • IT is full of jargon experts

    IT is full of people who are very good at spouting endless jargon, but know nothing about actually building systems. They spend most of their time in meetings talking to, and trying to impress, each other. They don't know what works and what doesn't. They try to purchase what they don't understand, and constantly jockey for political advantage. They always have someone set up to take the fall when the inevitable failure occurs. They are ravenously consuming IT resources, and management believes their polished delivery comes from real experts. Is it any wonder that new, innovative systems are not being built? The old systems are the legacy of an older generation that did know how to build systems. They are living far longer than anyone imagined, because the ability to replace them is absent.
  • Software History

    I started computer hardware design in the early 50s. We were always held to the standard that if you did the job right, the hardware would work. Software was held to a different standard. If it didn't work, maybe the specs were incomplete or conflicting, or the inputs were wrong. Most hardware could be broken down into separate elements, each of which could be tested individually and performance and interconnectability verified. Surprise outputs meant you screwed up the design. Most software was not designed as a standalone package, freely transportable and interconnectable with defined interface protocols. As far as I can see now, that is still pretty much the case. It is the difference between insisting on rigorously defined, consistent operating standards which are testable by anyone, anywhere, and " this will do such and such " with no guarantee it won't do a lot more , left untested. Essentially. it's the difference between ART and SCIENCE
  • chnage your processes where needed

    Saying that "it is horridly wrong" to sometimes insist that corporations change their processes is unfair. I work in IT for a company that has been in business in the same location for over 50 years. The processes which are followed are a reflection of the culture of this facility. We are in the (ongoing) process of implementing a new ERP, and it has been an extremely painful event to map out our existing processes. In many cases it has been more effective to follow the software process that figure out what ours was.
    The biggest resistor to change is the culture. When asked why some things are are done a certain way, the answer is most often "it's always been done that way!"