The new CIO of the US Department of Homeland Security, Richard Spires, told NextGov in an interview last week that he is personally reviewing 79 large DHS IT programs. According to the current US Government IT dashboard, CIO Spires has initially rated 11 of the 79 as being "red" or have significant concerns, 26 as being yellow, meaning they need attention, and 42 as being "green" or normal.

CIO Spires was quoted as saying, "We'll assess the program, and if it's fatally flawed, we'll stop the program. We're not going to continue to spend money for no benefit. [But] we haven't seen that yet." 

So far, CIO Spires has reviewed some dozen programs, and implies that the risks on those programs need to be better managed. He is also looking for systemic risks in managing or initiating DHS IT programs. He said that, "As we see issues and risks, I'm pushing that we address risks. We're doing that, and we're documenting those, and helping these programs improve on a tactical basis. But I also want to use that as a mechanism to discern where we have systemic weaknesses in managing programs."

Previously, CIO Spires was the CIO of the US Internal Review Service from 2007 through 2008.

Maybe this is the beginning of a trend. As we noted here, the CIO of the US Veterans AffairsRoger Baker earlier this year undertook a review of 45 IT projects there that were in trouble, then canceled 15 of them, and placed the rest on notice that they faced cancellation too if they didn't meet their commitments.

My oh my, holding government IT projects accountable: what a concept!

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
A plate of spaghetti made from code with a single strand of "spaghetti code" being pulled from the top of the frame in a neverending loop on a blue gradient background.
Shira Inbar

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less