Came here to say this. I still think that Linus Torvalds has the most profound advice to building a large, highly successful software system:

"Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project."

-- Linux Times, October 2004.

▲ tsimionescu 21 hours ago | parent | next [-]

I don't think this applies in any way to companies contracted to build a massive system for a government with a clear need. Linus is talking about growing a greenfield open-source project, which may or may not ever be used by anyone.

In contrast, if your purpose is "we need to manage our country's accounting without pen and paper", that's a clear need for a massive system. Starting work on this by designing a system that can solve accounting for a small firm is not the right way to go. Instead, you have to design with the end-goal in mind, since that's what you were paid for. But, you don't launch your system to the entire country at once: you first use this system designed for a country in a small shop, to make sure it actually handles the small scale well, before gradually rolling out to more and more people.

	▲	mrweasel 18 hours ago \| parent \| next [-]
		> for a government with a clear need. There's your problem. The needs are never clear, not on massive systems. Governments will write a spec, companies will read the spec, offer to implement it as written, knowing full well that it won't work. Then they charge exorbitant fees to modify the system after launch, so that it will actually full fill business needs. The Danish government is famous for sucking at buying massive IT systems. * Specs for new tax system: 6000 page, tax laws not included. That's basically impossible to implement and it predictably failed. The version that worked: Implement just the basics to collect TV license fees. The build from there. * System to calculate the value of people home, I think we're at round five (rumors has it that one system worked, but was scrapped because it showed that most home are massively overvalued and it do terrible things to the tax collection in the municipalities). * New case management system for the police, failed, development never restarted. One suggested solution was to have the police hire a handful of the best developers in the country and have them produce smaller deliverable over a number of year. The money wasted could have funded 10 world class developers for ~30-50 years.
	▲	patmorgan23 11 hours ago \| parent \| prev [-]
		Building those systems is a long term project, and you have to start small with a minimum number of functions, scope creep on those initial use cases often kills these kinds of projects.

▲ ozim 20 hours ago | parent | prev | next [-]

No Linus Torvalds would stand against people in projects from article, he would slam the door and quit.

Those projects that author pointed out are basically political horror stories. I can imagine how dozens of people wanted to have a cut on money in those projects or wanted to push things because “they are important people”.

There is nothing you can do technically to save such projects and it is NOT an IT failure.

▲ nly 19 hours ago | parent | prev | next [-]

Works with implementations and not APIs though.

A bad API can constrain your implementation and often can't be changed once it's in use by loads of users. APIs should be right from day one if possible.

	▲	globalise83 18 hours ago \| parent [-]
		I would add the nuance that the possibility of controlled migration from one versioned API to another should be right from day one, not necessarily the first API version.

▲ ambicapter a day ago | parent | prev [-]

This is a really dense paragraph of lifetime-accumulated wisdom in that single quote.