[steven777400]

I work for the government (and perhaps more significantly, have never worked as a developer outside of government), so it's difficult for me to understand the ideas and concerns promoted here. Just as in private industry (according to the article), our first versions are MVPs which have a roadmap for future additions and improvements. Based on funding, those may or may not result in an increase in team size.

At some point though, the team will decrease in size and the software will be considered "complete for now". Generally, that software will continue to be "on life support" (I guess you could say that?) for the next 5 - 20 years. That isn't a bad thing. Some of the projects I maintain have code from the mid-90s that I'm still making incremental updates to. Sure, I'd like to rewrite it in something newer, but it isn't about me, it isn't about fancy shiny. It's about the fact the system as it exists is proven and solid and meets 90% of the customers stated need. "Whack-a-mole" changes are just a sign of poor testing, poor architecture, or lazy developers. All of our teams here make incremental changes on aging software and generally don't experience major regressions except when it's time to do the big rewrites (which are usually customer-initiated when they bring a raft of changes and some money). When existing technologies are so obsolete as to be unsupportable, then we (IT) will initiate a rewrite as well, but hopefully with incremental upgrades we can keep a product running for as long as the customer likes without spending any more money than they want to spend.

[sarahallen]

Steven -- I applaud your team's approach. From my two and a half years in government I have rarely run into projects like you describe. We have lots of legacy systems, typically built without automated tests. Often a vendor is hired to build a "complete" piece of software, then given a meager budget to "maintain" it.

[steven777400]

Thanks.

We have a lot of that issue of "hire contractors to build, then use FTEs to maintain". I try to push back where I can because contractors that know up-front that they won't have to support the system are often not inclined to either follow standards (which are less exciting, I know, but make maintenance more predictable) and/or not be concerned about avoiding excessive technical debt up front.