Comment by djKianoosh | Hacker News Reader

Comment by djKianoosh | Hacker News Reader

Parent Full thread

"This fits neatly into the point I was making recently about government projects always being doomed because they end up with bad developers on projects with too many owners, and that governments everywhere should just buy off-the-shelf solutions and fit their way of working to them, rather than the other way around."

Initially I had a strong reaction against what you're saying here, but I see you chose your words carefully, saying gov projects "end up with bad developers on projects with too many owners". Sadly I have to agree, since I am in that world in the federal gov and see it first hand. But there are many highly talented developers here! They typically don't stay on projects long enough, so "end up with..." is exactly right.

And that does tie in to your point that "to get good software, you need good developers", so it's a never-ending challenge trying to find and keep those 10xers engaged and happy with their work so they tend to produce that 'good software'...

...or "buy off-the-shelf solutions" as brc suggested?

I don't think buying COTS or GOTS actually saves the government money in the long term. I dont have actual facts to back this claim of course, but it's just from many years of experience in this scene.

Many times the requirements of an agency/office/mission are too specific for something off the shelf. The solution has to be either completely custom or a mix of COTS/GOTS. And when you have a mix you have integration. Software is a smaaaaalll part of the equation in government. It's the solution engineering (read: consultants/contractors) that cost the most. And I bet you'll always need/want highly skilled engineers for all sorts of roles. innovation is one, but keeping missing critical systems alive and operational is important too. what qualifies as 'mission critical' is another subject for another day, and can vary wildly depending on who you talk to...

However, a lot of times, the requirements are truly simple, or simply met. And I think that's why you see a TON of Drupal being used in the gov these days. For many offices, that's all they ever needed. But even that's a smaaaaaal part of the pie. The government is huge! You can't imagine how many thousands of software projects are all going on at the same time right now...

This is my original point.

The vast majority of government IT systems are very ordinary things that are used all over the place.

Things like: payroll, issue tracking, asset tracking, emergency services management, waste disposal, vehicle registration, fines management and payment - the list goes on and on and on.

Yet time after time we find a government department insisting that their payroll system is unique because of x, y and z, and that their asset tracking system requires a custom solution.

This should be flipped on it's head and instead it should be : here are the top 3 whatever purpose systems available in the market. We will choose which one suits our needs the best, then we will change our work practices to best match the system.

Because changing the work practices will be easier and more successful than trying to build out (or customise) their own IT project.

But this requires people to think about practical solution, and to no have IT empire builders.

No government tries to re-invent railways, roads or sewage to their own needs- they look at what works elsewhere, and adapt to the technology available. Yet they go in the opposite direction when it comes to building computer systems. When you look at the graveyard of wasted billions on customised government computer systems - it's time for a new approach.

"Things like: payroll, issue tracking, asset tracking, emergency services management, waste disposal, vehicle registration, fines management and payment - the list goes on and on and on."

Most of those on the list are things that the gov already buys off the shell software for (I have worked as a network administrator at a large state university in the past). Our payroll system was off the shelf from Oracle, asset tracking was part of that erp system, our course management system was the off the shelf blackboard, security access system was from another vendor. It was rare that a project would be 100% built in house.

Using payroll as an example, for the size of these organization, the off the shelf components you will find are usually built with the expectation that it will be customized anyway. (Not all organization in government work the same way for very good reason. Laws) They are incomplete in a lot of cases and require integration with various system. The above poster was right, the problem is often integration. How to I plug my directory services into my erp system that connects to system for another agency somewhere. You will have a hard time getting a unified system across all agencies when you go by a biding system that is anywhere close to fair.

The companies that play in that space Oracle/SAP/HP/Novell whatever are all built on the assumption that you will buy something and need their help with it for years to come.

The problem is huge I feel you are underestimating it.

Reply on news.ycombinator.com