Since then I graduated high school, got a degree, got married etc etc. The time span is mind boggling. Would be interesting to see how continuity is maintained for so long. In software it feels like if a project is more than 6 months old, we throw it out and rewrite it.
I think that would be a bad way to operate, but what's worse is what we _actually_ do, which is write the project like it's gonna be replaced in 6 months and instead keep that poorly-documented untested duct-tape contraption around for a decade as the central load-bearing component of critical infrastructure.
I started on the program in August, 2010. I was 26 years old.
The program has just completed its Initial Operational Test & Evaluation, including its runs for score in the Joint Simulation Environment. I am 40 years old.
“The Phoenix pay system is a payroll processing system for Canadian federal government employees, provided by IBM in June 2011 using PeopleSoft software, and run by Public Services and Procurement Canada… By July 2018, Phoenix has caused pay problems to close to 80 percent of the federal government's 290,000 public servants through underpayments, over-payments, and non-payments.“
It's trendy in software to complain about doing annoying work like writing reports and documenting things. But most hard tasks require writing reports and documenting things.
Too often in the land of software we underestimate the potential negative impact the traditional "move fast and break things" approach to product development can have when it comes to real world use in mission critical systems.
Move fast and break things brings you to the Moon in a decade using primitive tech, where is total process compliance can't do that even in 50 years using much more advanced tech.
It's also quite important to remember how many lives were lost (or nearly lost) because of "breaking things" in the Apollo program. Something that's not nearly as acceptable today than it was at the height of the cold war. Something that directly implies moving more slowly and being more sure that everything works the first time, every time.
It can and did happen again, twice, on the shuttle project. Both the O rings and the ice damage were documented.
Ultimately, any process (or lack of process) can be subverted by a bad culture. And unreasonably excessive process - as perceived by the participants - can damage culture as much as not enough.
The problem is that culture is ineffable, so we try to nail it to the ground with whatever we can think of.
move fast and break things worked real well for the folks who got literally creamed while they were viewing the titanic.
I guess the ethos is quite different to top tech company. We don't get the pay or perks that you would get in Silicon Valley, but we are unionised, and it's a viable option to spend your entire career just on one project so it's very stable.
Partly it depends on documentation, but also on thinking long term. There are certain people who are the technical authority for a particular area, and they know that about 5 years before they retire or move on they need to find someone who can take on their role for at least the next decade, to keep their knowledge rolling forward.
If your project started 30 years ago, that means DOS, or Network or maybe one of the IBM behemoths?
Then the maintenance includes pacing OS updates and dependency changes?
In the 10 years after release that I was on that project, we went through multiple OS upgrades from Windows NT to XP Embedded, to Windows Embedded Industry (replacement for XP Embedded) and a number of replacement x86 CPU boards had to be qualified as one manufacturer after another exited the market. Since the device is validated as a complete system, we often had to buy a year or two stockpile of existing product to give us time to start the Validation process for replacement hardware.
You usually have plenty of warning from a supplier that a product (Windows or a CPU board) is going EOL at a certain point, so you need to start validating whatever the next replacement will be well ahead of time.