Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Maintenance by Skeleton Crew Is an Anti-Pattern

18f.gsa.gov

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Software Maintenance by Skeleton Crew Is an Anti-Pattern

#31

Post by dragonwriter »

enraged_camel wrote: post #30
jcadam wrote: post #21

I've worked O&M on software in the defense industry. Never again. On my current project, when development is done and we're officially transitioned over to "O&M", my employer either gives me a new project to work on or I'm leaving to do something else. Oh, and I've come to the conclusion that civil servants are not capable of grasping any development methodology other than 'waterfall.' Trying to do 'agile' is an exer…

It's not just civil servants who can't understand agile. Most non-software people can't. Which is totally normal and expected if you think about it: the agile movement started in software. You can't build a house or a plane using agile. It has to be waterfall.

> It's not just civil servants who can't understand agile. Most non-software people can't. Which is totally normal and expected if you think about it: the agile movement started in software.

Agile is (to the extent it has concrete substance) very similar to Lean, which (while it has come to software) actually started in manufacturing and engineering of tangible products. The difference between the two is mainly that Lean has a much stronger culture (and has thus also produced a lot more tools) around validation of methods through measurement, and thus is a lot more woo-resistant than Agile, which has proven to be decidedly prone to devolving in exactly the same kind of one-size fits all, consultant-pushed, top-down methodologies without good feedback on what works in the particular environment that the Agile Manifesto was a response to.

> You can't build a house or a plane using agile. It has to be waterfall.

"Agile" and "waterfall" aren't opposed, agile is opposed to the idea that any one methodology -- Scrum as much as Waterfall -- can be selected as right for a team without reference to the particular team and context in which they are working. To the extent that it works in a particular context, waterfall can be Agile.

Re: Software Maintenance by Skeleton Crew Is an Anti-Pattern

#32

Post by dragonwriter »

jcadam wrote: post #21

I've worked O&M on software in the defense industry. Never again. On my current project, when development is done and we're officially transitioned over to "O&M", my employer either gives me a new project to work on or I'm leaving to do something else. Oh, and I've come to the conclusion that civil servants are not capable of grasping any development methodology other than 'waterfall.' Trying to do 'agile' is an exer…

> Oh, and I've come to the conclusion that civil servants are not capable of grasping any development methodology other than 'waterfall.'

Civil servants are quite capable of understanding other development methodology. Civil servants actually involved in software development are often constrained by legal and regulatory regimes which no one in a substantively technical role has significant input into, which mandate procurement, risk-management, and approval processes which essentially mandate a high-level flow very similar to a completely non-iterative, cartoonish mockery of waterfall, and to the extent that they can attempt to implement more effective processes, they must do so within those constraints.

Re: Software Maintenance by Skeleton Crew Is an Anti-Pattern

#33

Post by Terr_ »

jcadam wrote: post #21

I've worked O&M on software in the defense industry. Never again. On my current project, when development is done and we're officially transitioned over to "O&M", my employer either gives me a new project to work on or I'm leaving to do something else. Oh, and I've come to the conclusion that civil servants are not capable of grasping any development methodology other than 'waterfall.' Trying to do 'agile' is an exer…

I see it in private industry too, I just worked in 2-week sprints on something only to discover that all our "feedback" for the past six months was actually from (surprise!) the managers in the pipeline, who hadn't actually enabled the feature to be seen by real end-users.

Among many possible causes, two that come to mind:

1. Managers who (despite lip-service to the idea) refuse to take any incremental risks looking bad with negative feedback each sprint, and would rather risk one big failure-event.

2. Companies which have either very-convoluted procedures or who try to treat end-users as cheap interchangeable human-robots... Which means no change can ever be rolled out without exhaustive documentation and training plans. Therefore all changes have to be "big enough" to be worth it.

Re: Software Maintenance by Skeleton Crew Is an Anti-Pattern

#34

Post by 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.

Re: Software Maintenance by Skeleton Crew Is an Anti-Pattern

#35

Post by pc86 »

enraged_camel wrote: post #30
jcadam wrote: post #21

I've worked O&M on software in the defense industry. Never again. On my current project, when development is done and we're officially transitioned over to "O&M", my employer either gives me a new project to work on or I'm leaving to do something else. Oh, and I've come to the conclusion that civil servants are not capable of grasping any development methodology other than 'waterfall.' Trying to do 'agile' is an exer…

It's not just civil servants who can't understand agile. Most non-software people can't. Which is totally normal and expected if you think about it: the agile movement started in software. You can't build a house or a plane using agile. It has to be waterfall.

> You can't build a house or a plane using agile. It has to be waterfall.

If you can build a car with it,[0] I'm sure you can build a plane.

[0] http://wikispeed.org/

Re: Software Maintenance by Skeleton Crew Is an Anti-Pattern

#36

Post by acveilleux »

azernik wrote: post #27
xigency wrote: post #16

Earlier quoted context omitted.

While this is changing, in game development the finished product ships on read-only media and without patches or online support, that is all the customer is going to get. Now there's a prevalence of day one patches but it's pretty lame to see developers waiting till the weeks between pressing the disc and it appearing on shelves to fix standing issues. In the case of M$ software that's a security or support issue not…

Already in 2013 92% of PC game sales involved no physical media [ http://gamerant.com/pc-digital-physical-sales-comparison-201... ]. This enables the day-1-habit, of course, but it also mitigates the problems - there aren't any shelves on which unpatched versions of the game keep sitting after launch.

Console is lagging behind for this.

Re: Software Maintenance by Skeleton Crew Is an Anti-Pattern

#37

Post by enraged_camel »

dragonwriter wrote: post #31
enraged_camel wrote: post #30

Earlier quoted context omitted.

It's not just civil servants who can't understand agile. Most non-software people can't. Which is totally normal and expected if you think about it: the agile movement started in software. You can't build a house or a plane using agile. It has to be waterfall.

> It's not just civil servants who can't understand agile. Most non-software people can't. Which is totally normal and expected if you think about it: the agile movement started in software. Agile is (to the extent it has concrete substance) very similar to Lean, which (while it has come to software) actually started in manufacturing and engineering of tangible products. The difference between the two is mainly that…

Agile is the idea that requirements are always in flux, and therefore it's pointless to spend time upfront gathering requirements and writing specs and following those specs since there's a good chance they will have become irrelevant by the time the product ships. So agile says "just get something, anything, out the door as soon as possible, receive feedback, then keep revising."

Waterfall is the opposite approach, where you have a formal requirements gathering phase, then you commit everything into design docs, and follow those docs with as few changes as possible. It's similar to how a house is built: first you check your local zoning laws, then have an architect draw the plans, then dig a hole and build a foundation, then build the skeleton, the walls, etc. You don't tell the client, "hey, we just dug the hole for the foundation, come live in it for a few weeks and give us feedback so we know what part to build next."

Re: Software Maintenance by Skeleton Crew Is an Anti-Pattern

#38

Post by kazinator »

xigency wrote: post #4

Without any concrete evidence or cases, the general description of a problem in this article is not very convincing. Software maintenance itself is not an anti-pattern. Instead, what is described is a situation of product/project mismanagement. > ... software is not considered complete when it's first released. I don't know where this assumption comes from. > Governments often use two anti-patterns... (2) moving to r…

Indeed, what is "complete" anyway? Is it the opposite of "incomplete" (all requirements are met)? Or does it mean "not requiring further extension" (no new requirements will emerge)?

Re: Software Maintenance by Skeleton Crew Is an Anti-Pattern

#39

Post by sarahallen »

steven777400 wrote: post #34

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…

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.

Re: Software Maintenance by Skeleton Crew Is an Anti-Pattern

#40

Post by steven777400 »

sarahallen wrote: post #39
steven777400 wrote: post #34

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…

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.

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.

Post reply on HN