Slashdot Mirror


FBI's Troubled Sentinel Project Delayed Again

gManZboy writes "The FBI's Sentinel project, a digital case-management system meant to replace outdated, paper-based processes, has been delayed again. The FBI's CIO and CTO bet big on using agile development to hasten the project's completion. But now performance issues have arisen in testing and deployment has been pushed out to May. It's the latest in a series of delays to build a replacement for the FBI's 17-year-old Automated Case Support system. In 2006, the FBI awarded Lockheed Martin a $305 million contract to lead development of Sentinel, but it took back control of the project in September 2010 amid delays and cost overruns. At the time, the FBI said it would finish Sentinel within 12 months, using agile development strategies."

96 comments

  1. the glass is half... by alphatel · · Score: 3, Funny

    Which is worse, that the FBI waited 4 years to kick Lockheed off the project or that the FBI has regained control of unfinished software?

    --
    When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
    1. Re:the glass is half... by AHuxley · · Score: 1

      4 years protected a lot of consulting and private sector "retirement" moves.
      You and your family are security cleared, ready to explore the private sector.
      Nobody wants to be the agent or listed as working under the agent who upset with the private sector contractor.

      --
      Domestic spying is now "Benign Information Gathering"
    2. Re:the glass is half... by Jah-Wren+Ryel · · Score: 4, Funny

      Which is worse, that the FBI waited 4 years to kick Lockheed off the project or that the FBI has regained control of unfinished software?

      The worst is the realisation that the only thing saving us from law-enforcement totalitarian nirvana is institutional incompetence.
      If they ever really get their shit together we are so screwed.

      --
      When information is power, privacy is freedom.
    3. Re:the glass is half... by man_of_mr_e · · Score: 2

      I think it's pretty damn impressive that they were able to finish the main functionality, and only need performance tuning in only a year.

      This should be celebrated, not mocked.

    4. Re:the glass is half... by rastilin · · Score: 1

      Maybe not. If they were the kind of people who were sharp enough to manage a project successfully then they wouldn't think that controlling everyone's information is a good idea. Both are manifestations of incompetence, so we're pretty safe.

      --
      How do you kill that which has no life?
    5. Re:the glass is half... by Jane+Q.+Public · · Score: 1

      It *IS* a convincing validation of Agile software development.

      It probably would be celebrated, if it weren't the FBI.

    6. Re:the glass is half... by gtall · · Score: 1

      Ah, you probably have not had a member of your family murdered and had to rely on the FBI to catch the perp.

    7. Re:the glass is half... by Jah-Wren+Ryel · · Score: 1

      Since most murders go unsolved, I think you've picked a fantastically poor rationalization.

      --
      When information is power, privacy is freedom.
    8. Re:the glass is half... by PPH · · Score: 1

      After 4 years of doing nothing more than contract management, did any competent developers stick it out for 4 years at the FBI?

      --
      Have gnu, will travel.
    9. Re:the glass is half... by Anonymous Coward · · Score: 0

      Most murders do not get the attention of the FBI.

    10. Re:the glass is half... by physburn · · Score: 1

      Very true. Seen thousands of TV shows about it though. There are three bad sides to being socialised into a climate of fearing the law. One is the paranoir of being a criminal the other is the paranoia of the being a victim, the third is a mind full of worse case scienios. Over all, it probably makes us safer, if more miserable. Perhaps Life is batman not the x-files.

  2. Re:They probably wrote it in Java by alphatel · · Score: 4, Funny

    Okay I turned it off. Chrome is working much bet.,,>.,>>

    --
    When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
  3. Agile strikes again! by viperidaenz · · Score: 3, Insightful

    Funny that, building software in small pieces and slapping them together doesn't while trying to shoe-horn in new functionality doesn't help you create a scalable system and meet all the non functional requirements.

    Disclaimer: Working along side an agile project with a 7 month "build phase" that is currently 15 months in and still hasn't delivered anything.

    1. Re:Agile strikes again! by Surt · · Score: 4, Informative

      Kind of missing the point of agile if you're 15 months in and haven't delivered anything. I mean, you can call it agile (you could also call it waterfall), but if you're not following agile practices, don't blame agile for the failure.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    2. Re:Agile strikes again! by timeOday · · Score: 1

      I appreciate your experience, but let's not forget that no other methodology has a great record of delivering massive projects on-time and on-budget, either. Nobody executes flawlessly; the winner is whoever executes best.

    3. Re:Agile strikes again! by Synerg1y · · Score: 1

      I think...

      But now performance issues have arisen in testing and deployment has been pushed out to May

      Sum its up real nicely, it might seem infinitely complex, but there's actually several common reasons for this, and I'm sure I don't know all of them either...

      1. third party libraries that suck to begin w (ex. nhibernate)
      2. Dev time requirement changes: yep code on top of code has performance issues a lot, suits will NEVER figure this one out.
      3. No QC / under funded QC / bad QC process: some ppl nowadays expect the coder to QC their own work, please reference quote for typical result (only applies to massive projects like this).
      4. The FBI pissed lockheed off: Lockheed skeletons the dev project.
      5. Initial requires were a mess: self explanatory

    4. Re:Agile strikes again! by stms · · Score: 1

      It seems to work pretty well for Linux development.

    5. Re:Agile strikes again! by viperidaenz · · Score: 1

      They have been following 2 week sprints developing stories they've put on post-its after time wasting planning sessions. When I say haven't delivered I mean to production. They have delivered many builds to test but its full of defects.

    6. Re:Agile strikes again! by Darinbob · · Score: 4, Insightful

      I think most Agile projects don't really do it the right way, if there is such a thing. People use it as a magic bullet. They're never "behind" in a project as long as the sprints are done on time. There's a whole cottage industry of Agile consultants who go out and get paid to screw up your company for you.

    7. Re:Agile strikes again! by viperidaenz · · Score: 2
      The project I ran on the side was on time and only slightly over budget. It was a smaller project but it was developed as 3 separate "water-fall" releases of around 3 months each. 2 week sprints is not enough time to build the large parts or a complex piece of software. The second 3 month development was mostly taken up re-writing the core of the first release to make it easier to enhance.

      The only place I see the "2 week sprint" agile working is for trivial enhancements to an already well written piece of software.

    8. Re:Agile strikes again! by man_of_mr_e · · Score: 1

      Dude,

      This is how it's supposed to work. You can fix defects... You can't fix a system that isn't even working a little bit.

      This is how open source works. Get something working, anything.. and then define the changes to get to where you want to be.

    9. Re:Agile strikes again! by man_of_mr_e · · Score: 1

      If a piece of functionality takes longer than 2 weeks to finish (maybe not QA'd finished code, but developer finished) then break it down to smaller pieces that can be finished in two weeks. It's not that hard, but lots of developers make it much harder than it has to be.

    10. Re:Agile strikes again! by hedwards · · Score: 1

      Or you could do it like they did back in olden days where you figured out what the code should do in basic terms then went about writing the code. If you're not going to bother to follow a plan up until the point where you've covered the things that you need, then I'm not sure why you'd expect to ever finish.

      I'm not really sure I understand why one would expect to program without a game plan and then wonder why later on it's taking so long to optimize and generally fix.

    11. Re:Agile strikes again! by viperidaenz · · Score: 4, Insightful
      What they've build is a hodge podge of pieces that have been built against half finished other pieces since they dropped everything at the end of 2 weeks and started the next sprint with their waste-of-time planning sessions where they spend half a day pulling numbers out their ass to estimate the build length of a story of less than 10 words. Every time they fix a bug in one place they uncover/create another one somewhere else. This isn't how open source works.

      I've failed to find any Agile success story for a large project. All I find is marketing hype and buzzwords from vendors selling Agile training and mentoring services.

      Agile is no silver bullet or golden hammer. It all seems a bit more like the Emperors New Clothes to me.

    12. Re:Agile strikes again! by plopez · · Score: 1

      Agile has some good ideas, but what I see is that it became the latest flavor of the month and has been implemented by many who don't have a clue as to what it is.

      --
      putting the 'B' in LGBTQ+
    13. Re:Agile strikes again! by Jane+Q.+Public · · Score: 1

      "They have been following 2 week sprints developing stories they've put on post-its after time wasting planning sessions. When I say haven't delivered I mean to production. They have delivered many builds to test but its full of defects."

      Delivering to production IS "delivery". Putting it on a staging or testing server isn't.

      It's pretty safe to say that 15 months ain't Agile. On certain really huge projects, maybe. But rare.

    14. Re:Agile strikes again! by Jane+Q.+Public · · Score: 2

      "2 week sprints is not enough time to build the large parts or a complex piece of software. The second 3 month development was mostly taken up re-writing the core of the first release to make it easier to enhance. The only place I see the "2 week sprint" agile working is for trivial enhancements to an already well written piece of software."

      Then you don't understand how Agile is supposed to work.

      Admittedly, there should be some amount of basic architecture roughly hashed out before a project starts. (No, I'm not talking waterfall, just a basic grasp of the big picture.)

      Then management (if they know what they are doing), come up with "stories". So far, so good. But it appears that your stories were not conceived at the proper scale.

      If a story is too large, then it needs to be broken down into smaller stories that CAN be performed in one iteration ("sprint" if you're doing Scrum). If they weren't, then your stories were not created properly.

      Part of the purpose for your once-per-iteration meetings (or "standups", or whatever you call them), is to determine your velocity (stories the team completes in one iteration). If your velocity is too low, or even -- Grid forbid -- less than 1, then your stories are too big. It is as simple as that. It is then up to management to refactor their stories. Period.

      Different groups do it different ways, but one good rule of thumb is to shoot for a velocity of at least one story per person per iteration.

      It is ALWAYS possible to break a story into sub-stories if necessary, all the way down to individual lines of code. It doesn't matter whether your iteration is 2 weeks long or 2 days. If stories don't get completed, the stories are too big.

      What you are telling us is not that there is anything wrong with Agile practices, but that somebody there did not know how to do it right.

    15. Re:Agile strikes again! by sjames · · Score: 4, Insightful

      Like most such management fads, it is an attempt to capture the success of existing teams. The problem is, the successful teams were employing a great deal of experience and common sense in a flexible manner. That is, their one rule was "do the right thing". When you have an experienced and conscientious team that knows what "the right thing" is, and a management that's smart enough to stay out of their way, magic happens.

      Alas, at the same time it gets a marketing name stamped on it, it is cast into a series of inflexible rules and chopped into sound bites for managers to spew back later. Rather than staying out of the way, management pesters incessantly to make sure everyone is doing exactly 'flavor of the week' exactly as they (mis-)interpret it. Nobody is even thinking about doing 'the right thing', they're too busy playing language lawyer with the magic juju manual that defines 'flavor of the week'. Meanwhile, the whole team forgets that 'flavor of the week' isn't actually the deliverable, it is supposedly just a means to get to the deliverable.

      In it's most extreme form, a team infected with 'flavor of the week'-ism begins to eerily resemble a creepy cult complete with special meanings loaded onto common words and phrases and reverence to the leader (author of the book/consultant) and a group blindness for the whole herd of elephants in the room.

    16. Re:Agile strikes again! by Anonymous Coward · · Score: 0

      Tread lightly, here be agile zealots.
      There can be NO fault in the agile religion, only you as the practitioner is at fault.

    17. Re:Agile strikes again! by Serious+Callers+Only · · Score: 2

      I'm not really sure I understand why one would expect to program without a game plan

      It's quite possible to mess up both agile and more traditional styles of development - obviously neither approach is a magic bullet which will transform a bad team/product into a good one.

      To address your specific concern above, agile is a response to some obvious failures of the top-down model - sometimes it's very hard to pin down requirements in advance, or they simply change because of external factors, or the wrong people are asked for requirements, which doesn't become clear till the software is delivered after a long period of work isolated from use, broken as designed. That means trying to plan everything in advance doesn't always work, and *sometimes*, with the right team, it's easier to start with a basic app which works well in a very simple way, and then build up layers of features as you decide which things are actually important to your users.

      Now in some cases it's easy to define all requirements in advance, the use-cases are very simple, the users few and clear on what they want, and an agile approach is not really required, in others with lots of potential users/use-cases sometimes it's better to start small and work up to something bigger, or there's a danger you'll never finish.

      Of course this can go horribly wrong if you use it as an excuse to never properly define requirements, never solicit proper feedback from users, or to just hack up any old thing and call it finished. There is no system which can deal with bad attitude, lack of effort or incompetence, and there are many ways to mess up every project - if you have the wrong team and leadership they'll find every possible way to make things go wrong, no matter which approach you take. No idea what went wrong here, but it's unlikely to be development methodology and far more likely to be the result of politics and infighting between different departments and users.

    18. Re:Agile strikes again! by viperidaenz · · Score: 1

      can you tell me how long a story will take to code before you code it? add in to the mix it has to work seamlessly with the other stories that make up the same UI element that other people wrote and fit in to the same work-flows. Re-factoring the work done in the other stories as well so yours can fit. Wouldn't it have been easier if instead of adding two controls to a screen and mess around connecting everything up, removing old stubs, fixing shortcomings of related code because the person writing it didn't have access to the entire set of stories that make up the screen because someone thought it was a good idea to break up what was essentially a single piece of functionality into inter-related stories because doing it all at once would have taken 4 weeks, splitting it up into 20 pieces can now be done in 5 2 week sprints. Efforts shouldn't be split based on how long someone things it would take to write it in isolation. they should be split at natural boundaries.

    19. Re:Agile strikes again! by viperidaenz · · Score: 1

      It's pretty safe to say that 15 months ain't Agile

      The project that TFA is about was "made agile" in September 2010, 17 months ago.

    20. Re:Agile strikes again! by sjames · · Score: 2

      Sure, you can (and should) break it into smaller chunks, but if they're part of a greater whole, the right thing to do after finishing one is to move right on to the next with nothing more than a celebratory cup of coffee in between. All the smaller chunks are going to do is run their minimal self tests at that point anyway, so there's not much to show anyway.

      If you're taking a break because that's what some methodology says you have to do, you're doing it wrong.

    21. Re:Agile strikes again! by Jane+Q.+Public · · Score: 1

      Even worse.

      Although I should qualify that: I do agree that "inheriting" an existing project can sometimes be much worse than just building one from scratch.

    22. Re:Agile strikes again! by Jane+Q.+Public · · Score: 2

      "can you tell me how long a story will take to code before you code it? add in to the mix it has to work seamlessly with the other stories that make up the same UI element that other people wrote and fit in to the same work-flows. Re-factoring the work done in the other stories as well so yours can fit."

      That's why it's called an iterative process. Each time you have a standup or scrum, you make adjustments, until it works the way you want it to.

      I don't know what to tell you, man. Other people make it work. It worked for us just fine, when I was in an agile shop. And I don't think we would have gotten nearly as much done using more "conventional" methods.

    23. Re:Agile strikes again! by sjames · · Score: 1

      Linux development is agile but not Agile.

    24. Re:Agile strikes again! by Anonymous Coward · · Score: 0

      It was a smaller project but it was developed as 3 separate "water-fall" releases of around 3 months each

      It does sound that you did iterative development yourself, so the argument here is really not to defend the classic waterfall method. If parts of the project are large and complex as viewed from the perspective of the external customer, divide the monster and throw internal customers to the mess. As a bonus you will likely end up with more decoupled system with a clear view of the functional requirements. Then you just refactor, or couple and block for performance.

    25. Re:Agile strikes again! by somersault · · Score: 1

      I think similar things every time I see people raving about the latest programming language or framework. Some of these things are good, but I tend to wait to see how things stand the test of time before wasting time on them myself.

      With project management and development practices you can read and learn a lot of interesting things, but often they don't really click until you've experienced them for yourself. And even if you know something to be true, good luck trying to convince your clients or management how things should actually be done.

      --
      which is totally what she said
    26. Re:Agile strikes again! by Surt · · Score: 1

      So your claim is that your team delivers two weeks worth of work to test, it's packed with defects, and agile is the problem?
      Your problem is that your team can't deliver even two weeks worth of work without defects. Imagine how many defects they'd have if you waited a whole year to find out!

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    27. Re:Agile strikes again! by Surt · · Score: 1

      Absolutely. But you can do any process wrong, and waterfall is in many respects much easier to screw up.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    28. Re:Agile strikes again! by Surt · · Score: 1

      We use agile on our large projects at Guidewire. We have over 100 successful enterprise customers, some of the largest insurers in the world. We've been doing it for multiple software generations now.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    29. Re:Agile strikes again! by man_of_mr_e · · Score: 1

      I'm really not sure what you mean by "taking a break because that's what some methodology says you have to do" means. Agile does not say you have to take breaks..

      I think you are confused by what agile is. It doesn't mean "Only do the work allocated to you for this sprint", Sprints can and should be adjusted if you have more work than can be done or not enough. And it's ok if you don't finish your work within the sprint, you just continue working on it in the next.. but if this happens too much you really should consider breaking it into smaller pieces.

    30. Re:Agile strikes again! by sjames · · Score: 1

      If there's no way to notice when one 'sprint' ends and the next begins, then it isn't anything at all and shouldn't have a name. If you can tell then it is a break in the flow of programming and shouldn't happen when you're in the middle of something. If it should be as long or short as you want, then what was wrong with 3 months? If you're building the framework, there may not be a natural breakpoint until it's done. Try as you might, if you treat the Boston Marathon as a series of sprints you will come in dead last every time.

    31. Re:Agile strikes again! by datavirtue · · Score: 1

      The team is most likely too large. This will exacerbate any communication and QC issues. I can just imagine the poor programmers working on this turd. Please hit thedailywtf.com guys; we want to hear your stories.

      --
      I object to power without constructive purpose. --Spock
    32. Re:Agile strikes again! by man_of_mr_e · · Score: 1

      Sprints can be as long as you want. However, the shorter the better. Sprints are all about course correction. At the end of a sprint, you review where you're at and what you're doing next. You try to plan enough work for a sprint, but you don't HAVE to make it only one sprint. It's best practice though.

      Like anything, if it had absolutes, it wouldn't be feasible. It's never possible to do everything in a strict methodology, it has to have some wiggle room.

    33. Re:Agile strikes again! by rwven · · Score: 1

      Then it's not agile:

      Waterfall = sacrifice delivery date to maintain features.
      Agile = sacrifice features to maintain delivery date.

    34. Re:Agile strikes again! by sjames · · Score: 1

      At that point, you're actually doing 'the right thing' and back justifying it to management by casting (or coercing) it in terms of 'flavor of the month'. That's the next best thing to the ideal do 'the right thing' I mentioned previously.

      Ideally, if it feels like things are off track when you're talking at the coffee pot, it doesn't matter if you're in the middle of a sprint, three legged race or piling into the clown car, you should re-evaluate and correct course no matter what the chart says is on the agenda. OTOH, if all is going well and everyone is being productive, do not under any circumstances interrupt the flow.

      If that needs to be Agile for managerial reasons, so be it ;-)

    35. Re:Agile strikes again! by Darinbob · · Score: 1

      Agile seems oriented to work best with projects that are already done and need maintenance and new features, or variations of existing designs, or smaller projects. Those things can be split up into tiny sprints. But very large projects that need extensive design don't easily get done this way. I've been on several projects where for two weeks solid I have written zero lines of code, and in Agile that's considered blasphemy. This FBI project just sounds like something so big and complex that you can't squeeze it into the Agile style.

      The majority of projects I think use neither agile nor waterfall. Despite all the faults waterfall has at least it isn't so absurd that it has a manifesto.

    36. Re:Agile strikes again! by viperidaenz · · Score: 1

      Agile = sacrifice delivery to maintain delivery date.

      FTFY

    37. Re:Agile strikes again! by Surt · · Score: 1

      I would definitely not think of size or complexity as barriers to agile.
      The design issue you're describing is usually thought of as a spike:
      http://agile101.net/2009/09/29/using-%E2%80%98spikes%E2%80%99-in-agile-software-development/

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    38. Re:Agile strikes again! by Anonymous Coward · · Score: 0

      I would assert that you are in fact not working along side an Agile project.

    39. Re:Agile strikes again! by HereIAmJH · · Score: 1

      The project that TFA is about was "made agile" in September 2010, 17 months ago.

      That part of the article really bothered me. They talk about Agile and two week sprints, then go on to tell about the system test in October that failed. From the article it sounds like no one is using the system because it isn't deployed. What are they doing at the end of their 'two week sprints', because they obviously aren't rolling any code to production.

      Admittedly they are taking over an existing project, so release schedules could be short. But two weeks seems awful short. I would think 2 months would be more productive. But in the process of changing from Waterfall to Agile I would think you'd have to say some parts of the system are done, or will be at the end of the first work period, and then all the incomplete functionality would be assigned to future releases. If all you're doing is 'deploying' to test and saving everything for a massive rollout, then I hate to break it to you but you are still doing waterfall.

      And I just felt all warm and fuzzy when I saw near the end of the article that they went back to Lockheed Martin to upgrade the hardware for the system they failed to build. Fool me once, shame on me. Fool me twice....... idiots. Maybe you shouldn't hire your executives from businesses that failed spectacularly.

      --
      Another day, another update to a Google android app.
    40. Re:Agile strikes again! by rwven · · Score: 1

      Bollocks. I've been on agile dev teams for years now, and we have consistently hit, or beat deadlines. The reason "agile" usually fails, is the same reason that waterfall usually fails. Bad development practices, poor project management, and a failure to actually understand and properly practice the development method itself.

      Most self-proclaimed agile teams are really just practicing glorified cowboy coding. Newsflash: That's not agile. TRUE agile, like TRUE waterfall, requires lots of discipline and strict adherence to the rules of the game.

  4. Reasons for failure by Anonymous Coward · · Score: 5, Informative

    From Wikipedia on software development projects.

    analysis of software project management failures has shown that the following are the most common causes:
            Unrealistic or unarticulated project goals
            Inaccurate estimates of needed resources
            Badly defined system requirements
            Poor reporting of the project's status
            Unmanaged risks
            Poor communication among customers, developers, and users
            Use of immature technology
            Inability to handle the project's complexity
            Sloppy development practices
            Poor project management
            Stakeholder politics
            Commercial pressures

  5. Apart from anything else by Presto+Vivace · · Score: 2

    Sentinel is not NIEM compliant.

    1. Re:Apart from anything else by Surt · · Score: 1

      I have a hard time deciding if that website is satire or not. If it's a fake ... it's an impressively detailed one.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    2. Re:Apart from anything else by Presto+Vivace · · Score: 1

      Not a fake; the US Government site for the National Information Exchange Model, the standard for xml for law enforcement.

    3. Re:Apart from anything else by Anonymous Coward · · Score: 0

      I'm pretty sure Random J. Bob can't buy a .gov

    4. Re:Apart from anything else by sjames · · Score: 1

      Consider how many government offices have gotten an F in network security....

    5. Re:Apart from anything else by Anonymous Coward · · Score: 0

      Check out the standards work that has been done on Federated Identity Management under the Department of Justice Bureau of Justice Services. (Google GFIPM) I think you will find some good efforts there.

      And... I might mention.. when was the last time that you saw an information leak from the US Federal Courts? They have a serious security program.

      So while it is fun to throw accusations at the feds, you never hear about the agencies that do a good job.

    6. Re:Apart from anything else by sjames · · Score: 1

      All true, but all you need is one single agency to fail to secure their web server (one of the ones that did get an F) and you now have a joke .gov site.

  6. Agile technics... by stanlyb · · Score: 1

    Meaning one developer is working while another agent is standing next to him, with a gun pointed at his head, and waiting for the compiler to produce even one error......
    The senior developers are permitted to have only one warning, no more.....

    1. Re:Agile technics... by hguorbray · · Score: 1

      Oxymoronic -Government AND Agile? pick one

      I'm just sayin'

    2. Re:Agile technics... by Anonymous Coward · · Score: 0

      The agent is no different than normal, agile just means they have to dodge the bullet...

    3. Re:Agile technics... by Sulphur · · Score: 1

      Meaning one developer is working while another agent is standing next to him, with a gun pointed at his head, and waiting for the compiler to produce even one error......

      The senior developers are permitted to have only one warning, no more.....

      Shot is warning to next guy.

      Yakov Smirnov

  7. $305 million? by Anonymous Coward · · Score: 1

    Seriously, does this thing have some amazing AI or other sci-fi requirements? Infinite zoom?

    1. Re:$305 million? by plover · · Score: 1

      Seriously, does this thing have some amazing AI or other sci-fi requirements? Infinite zoom?

      AND enhance!!

      --
      John
    2. Re:$305 million? by hedwards · · Score: 1

      Don't worry that money didn't come out of their budget for looking at child porn. Er, for child porn, for.

  8. win for freedom by Anonymous Coward · · Score: 0

    Carnivore didn't work either from what I remember. It's worth it so long as their dollars are wasted.

    1. Re:win for freedom by hedwards · · Score: 1

      The problem with that is that things like the FBI, DoD and other agencies that are particularly useless never seem to be affected by GOP cost cutting the way that useful things like the FAA, FDA and DSHS are.

    2. Re:win for freedom by Jane+Q.+Public · · Score: 1

      I would debate even those.

    3. Re:win for freedom by gtall · · Score: 1

      Hi, I don't know a damn thing about the FBI, DoD and the other agencies either, can I subscribe to your newsletter?

  9. Agile at this late phase of project by monopolarbear · · Score: 1

    the FBI said it would finish Sentinel within 12 months, using agile development strategies.

    IMHO, this translates to: "We are going to duct-tape whatever we already have together and deliver a project which more or less fulfills initial (or revised) requirements, meanwhile being an unmanageable piece of s***. Heck, we are going to build it from scratch one decade later, anyways." On the other hand, I do not have any clue about the nature of problems encountered in this project, so above statement might or might not be a fair conclusion.

  10. Time for a new chapter in methodology by Anonymous Coward · · Score: 2, Interesting

    http://programming-motherfucker.com/

    We are a community of motherfucking programmers who have been humiliated by software development methodologies for years.

    We are tired of XP, Scrum, Kanban, Waterfall, Software Craftsmanship (aka XP-Lite) and anything else getting in the way of...Programming, Motherfucker.

    We are tired of being told we're autistic idiots who need to be manipulated to work in a Forced Pair Programming chain gang without any time to be creative because none of the 10 managers on the project can do... Programming, Motherfucker.

    We must destroy these methodologies that get in the way of...Programming, Motherfucker.

    1. Re:Time for a new chapter in methodology by cowdung · · Score: 1

      umm.. that is what we started with in the beginning..

    2. Re:Time for a new chapter in methodology by WOOFYGOOFY · · Score: 1
      There's more than a little truth to what you say.

      Reading the article, I don't think it was an issue with Agile. I think what the FBI was saying was they're going to try to go ahead on their own, using Agile.

      Not an Agile guy myself, but the top practitioners of this- Martin et al are known to be highly competent.

    3. Re:Time for a new chapter in methodology by phantomfive · · Score: 1

      Uh, that's great, there's nothing I love more than spending a day programming, but how do you know what to work on? That's the whole point of these methodologies, making sure you program-motherfucker on the right thing. Doesn't help much to write a statistics package if your customer wants a VPN client. Doesn't help much to write a networking framework when all you need is to make one HTTP request. Doesn't matter how many new features you add if the previous ones are all so buggy they don't work.

      But going in and programming without knowing what to do is fun.

      --
      "First they came for the slanderers and i said nothing."
  11. Give a chainsaw to a platypus... by Shoten · · Score: 2

    One of the problems here is that government contracting works best when it uses swarm theory. You have to think of the workers as ants...individually unintelligent, intended for single- or few-purpose roles at best. When you set goals using techniques and methods that require a more versatile kind of individual...well, you will fail, because recruiting aims for people who are less expensive. And the recruiting is driven by the procurement, which also drives costs down. Get bottom dollar for a project, and you have to give bottom dollar for the people, and get bottom dollar for performance. Agile development requires a bit more mental agility than most contractors I've seen possess. (Full disclosure: I work for a company that does a lot of contracting for the Federal government.)

    --

    For your security, this post has been encrypted with ROT-13, twice.
  12. News by DnaK · · Score: 1

    Government agency pushes back date for project and asks for a few hundred million more. News at 11.

  13. The primary problem is they didn't use... by Assmasher · · Score: 1

    ...a software company. They went to a bunch of government hack jobs like Lockheed Martin.

    They can build an airplane, but I can tell you from personnel experience with 3 different divisions of theirs (ones doing military simulation, ones doing wide area security, and ones doing AI driven content management) they staff their people with plodders.

    I don't mean the people aren't capable of writing some software, but it is TOTALLY beyond them to write a complicated system. I would never hire any of the people I interacted with over there. I'm not some friggin' elitist either, I'm good, I'm not great. These guys don't even approach good in a general sense.

    I'm sure there are some good software engineers there, you just never meet any of them.

    305 million dollars? FFS, There's no software project on earth that should cost HALF of that. Hardware, data entry, support, upgrades, everything included. It's ridiculous.

    --
    Loading...
  14. Wast of Money by ZombieBraintrust · · Score: 1

    Why they building Sentinels. Their aint no such thing as mutants. Those nerds need to stop reading comic books.

  15. I can't see that changing by dbIII · · Score: 4, Informative

    They still use a magic lasso lie detector machine invented by the writer of Wonder Woman and adopted by the FBI when their notoriusly corrupt leader J. Edgar Hoover was busy accepting kickbacks. Incompetence like that (unwillingness to fix obvious mistakes) is at the very core of their organisation and has made them an International laughing stock.

  16. too many suits by p51d007 · · Score: 1

    The problem with a huge bureaucratic octopus like the government, is that there are so many idiots that have to have their thumbs in the pie, that by the time everyone signs off on it, the project is 10+ years behind and the hardware & software is out of date. The FAA has been trying to replace radar systems at airport centers for a long time and when they are about to install it, they find out it's 20 years old and try to update it, starting the cycle again and again.

  17. 305 Million Dollars? by Anonymous Coward · · Score: 0

    when they could just have downloaded the software from isohunt or demonoid. Or had chinese kids do it in a weekend.

  18. Yet another Big Company / cheap labor disaster by WOOFYGOOFY · · Score: 1
    At least the FBI seems to have wised up to Agile methods, which implies they're actually going to go ahead and hire real programmers as opposed to the cheap labor places like Lockheed Martin and IBM are stuffed to the gills with.

    The rubber has to hit the road somewhere. Maybe you can contribute to your Senator's re-election campaign and get legislation that gives you visas for ten million programmers who will all work for 25 bucks an hour 12 hours a day 6 days a week, live 6 to an apartment and when their six year contract is up, all go home exchange rate adjusted millionaires.

    But somewhere on some machine, ultimately, code has to run without errors.

    Rubber, meet road. Road, meet rubber.

    I love it when fast buck, coke snorting, prostitute screwing, sexual harassing, hard drinking, low IQ, high ambition, hand pumping, bribe giving, sales men dirtbags come face to face with something the rest of us know as non-negotiable reality.

    It doesn't make up for the career swath of career destruction they've cut through the industry, but still.

    "Hey ! Does anyone here know how to program? "

    One thing is, companies learn their lessons. My spouse's company outsourced everything and after a years time brought it all back and now everyone's job is VERY secure. They'll never do THAT again.

    Same thing here. Bet you anything the FBI is hiring programmers right now after having seen the advantages of developing and maintaining their own supply of stable, competent craftsman -programmers.

    IBM Lockheed SAP Deloitte SAIC Technodyne and all the rest are in the business of billing bodies by the hour. Full stop. The more hours they bill, hey man, the better the business is. These are of course the same companies who lobby Congress to import as much programming labor as possible to undercut the domestic market.

    I bless anyone anywhere who wants to be a programmer or make money for themselves and their families. That doesn't stop me from observing that Mega Corporations cynically exploit those same people and systematically undermine the quality of the work product of the entire industry by first staffing with masses of unqualified programmers, then paying substandard wages, then systematically overworking them all of which has the effect of causing people who wanted to make a real lifelong career of their craft to be forced out of their careers and also having the effect of making an IT career seem like a route to a short lived, overworked and underpaid job to people who are considering it as a major.

    As far as these projects go, in the end, none of it works. Like making the WRONG choice for your prom date, you as a project manager only have to hook up with any of these sleazy companies and wait nine months to turn yourself into the sorriest motherfucker on your block.

    http://www.usnews.com/news/blogs/washington-whispers/2011/12/20/indianas-gov-daniels-assailed-by-ibm

    http://www.pcworld.com/businesscenter/article/218515/county_alleges_sap_deloitte_engaged_in_racketeering.html

    http://www.pcworld.com/businesscenter/article/237939/epicor_sued_over_alleged_erp_project_failure.html

    http://www.cio.com/article/678553/Auditors_ERP_Software_Woes_Could_Cost_Idaho_Millions

    http://www.computerworlduk.com/news/it-business/3302164/lawson-embroiled-in-erp-lawsuit-with-customers/

    1. Re:Yet another Big Company / cheap labor disaster by Anonymous Coward · · Score: 0

      What you just said was awesome. My only gripe is that most Federal Contractors aren't importing most of their developers. These big companies do despise the more talented workers though. After 3-5 years you have to start looking at being a project manager and bringing in business to benefit the paper mill. I know a few decent programmers that decided they just couldn't take the moral beating. My only solace is starting my own consulting business with different values. Too many people don't care.

    2. Re:Yet another Big Company / cheap labor disaster by HereIAmJH · · Score: 1

      Bet you anything the FBI is hiring programmers right now after having seen the advantages of developing and maintaining their own supply of stable, competent craftsman -programmers.

      You're much more confident than I am. The Federal government is the leader in NIH. (Not Invented Here) 'Smaller Government' is all about out sourcing everything possible to private businesses.

      --
      Another day, another update to a Google android app.
    3. Re:Yet another Big Company / cheap labor disaster by WOOFYGOOFY · · Score: 1
      How right you are about smaller government and it's proponent's desire to outsource everything (to their buddies companies..).

      But the FBI and CIA and especially the armed forces are serious people who actually work in government because they believe in government of a specific kind- good government.

      Among serious adults, not about big government or small government, it's about GOOD government and towards that end, I'll wager, they're rethinking the in house craftsman / vs cheap ?? outsourcing debate internally.

      Just a hunch.

  19. Obligatory Dilbert by Kikuchi · · Score: 1
    --
    There's no scientific consensus that life is important.
  20. Big government run computer projects always fail by digitaldude99 · · Score: 1

    Most big computer project run by the governments fail. Looking at my home in the UK, the government had this big idea about computerizing the air traffic control system and it all went wrong. They did the same with an attempt to computerize everyones health records and then repeated similar errors with an identity card system. I think the problem is maybe to do with people in government not really understanding the projects they are running. Another thing though, I read a declassified report by the CIA for a project done in the 50s which was about some guy investigating the use of the psychic powers of dogs and pigeons for the detection of land mines. It was one of the funniest things things I ever read. If you think about it, if a senior official of the CIA would spend good tax payers dollars on such a hair brained scheme, what is his reliability going to be on a some big technical project?

  21. 2nd Failure to replace old system by realsilly · · Score: 1

    This isn't the first time that the FBI has had a project to replace it's old software fail. Back in 2002 - 2004 they wasted approximately $160 million on a failed project. It even went through some congressional oversight afterward and the FBI was heavily scrutinized, as was the company (SAIC I think) that was performing the work.

    I have had direct experience as a team member on a government project, and I can tell you it is the Government's own fault for failure to see their contracted out projects fail.

    Here are some reasons:
    * Clearances, without the proper clearance in place you can't work on a project
    * Vague, if any clearly defined requirements
    * Govt. Project managers are never available and so meetings to resolve issues take months to happen
    * Strict detail of time management. The government often refuses to pay for meetings, but they are necessary to resolve issues
    * Govt. does not like to pay for people who aren't developers.
    * Govt. constantly changes the scope and refused to ever lock down requirements
    * DC is expensive, so to use contractors is cheaper, but they have to travel to DC sometimes, and that adds to the budget drastically
    * Govt. does not like to be told that they are wrong. The words "the project is at risk" gets the individual kicked from the project.
    * Contract companies are outside of the government and have their own needs to be met to stay in business, Govt. doesn't care, only just makes demands. ....
    and there are many more reasons, and those are but a few of the key reasons for failure.

    --
    Life takes interesting turns, but the most interest is when you're off the beaten path.
    1. Re:2nd Failure to replace old system by Mn3m0nic · · Score: 1

      I am currently working in the 'project management' office at the FBI on a similar project. Internally its referred to in the usual 4-5 letter acronym format. While I tend to agree with most of your reasons listed for failure, the FBI has recently (past year and a half) finally started listening to professionals in the project/program management field. They are forcing projects to be managed by a central department that is held accountable for all issues and risks. Almost nothing is green level in meetings anymore. If I am a PM (which I am not, just want to make that clear) and bring a report to the high-ups that lists budget, schedule, and risk as all green, there is a big problem. They WANT to know what any possible risk will be to the project, if anything is under or over budget, etc. It is no longer about spraying perfume over a pile of dog crap and hoping your boss doesn't notice its dog crap. Now he wants to know the possiblility of a dog getting into the yard to take a dump months before that might happen. It's a slow process changing people's minds, but it IS happening. Will it be perfect? Of course not.

    2. Re:2nd Failure to replace old system by realsilly · · Score: 1
      --
      Life takes interesting turns, but the most interest is when you're off the beaten path.
  22. Re:They probably wrote it in Java by physburn · · Score: 1

    Lets writing it in C, and leave bufffer overruns all over it. Thats what the FBI need. So they extradict teenage whiz kid for being able to crash it as easierly as dodgem car.

  23. and to think I blew the door open on this in 2003 by Anonymous Coward · · Score: 0

    The IG got involved and SAIC was tossed out on its ear and fined. I said it then I'll say it now, the system could be implemented by a competent team of a couple dozen to 50 at most. Agile or not, you could have implemented much of the system using COTS and readily available opensource. Hell, you could implement it in Sharepoint 2010.

    and yes, I read the requirements doc. all 2+ inches worth.