How do you call this fairly common anti-pattern?
-
This antipattern is as follows: version 2 is far from being ready, yet version 1 is already obsolete at best, unsupported at worst. No major shortcomings in v1 are fixed, because they "are fixed in v2", or "v2 is immune to them by design". But v2 is not production-ready, is missing many features people were relying on in v1, so the whole situation becomes a stalemate.
Also, how do you recognize this anti-pattern in software you're working on? How do you prevent it? How would you recover if you find yourself in the middle of it?
-
I call it "business as usual".
-
This seems more like a management problem than programming problem. The only solution is make the management care about v1 at least until v2 is released.
-
-
In commercial development, situations like that create a particularly unbalanced atmosphere. Version 2.0 gets the most and the best resources, the release dates get shifted all the time, and they begin to feel the project will never see the light of the day. Cue frustration and burnout.
At the same time, customers work with 1.x, they want to support 1.x, but all that support is transferred by a small team of people who "only" do "legacy support", and due to the very fact "we are releasing 2.0 real soon now", any requests to expand their team a little bit to cope with demand is rejected. Or, any request to allot time to implement a much needed feature for 1.x is declined, because "we already have it in 2.0" (which is not released).
-
Over here, we have kinda the opposite situation. We are part of a giant international corporation that makes a complete software stack for its devices. Our project is one of the middle layers. Every project has monthly major releases which are supposed to contain all the features planned for a given month and not get any more stuff. And we have minor releases with each commit to one of "trunks" (each release has its own "trunk" which we call "feature branch", in addition to the actual trunk). Of course, most things don't get done on time, so we frequently have to commit massive changes to a feature branch long after it's already done. About 95% of commits are breaking changes.
Also, it's a very frequent occurence to have a brand new feature planned after the feature branch is made, which defeats the purpose even more. Not to mention bug fixes, which often mean even more code and even more breaking changes than features themselves. And those features and bug fixes have to be backported to earlier feature branches - most, but not all of them; enough to have nearly identical functionality on each of them, but also little enough for the code to noticably diverge, making merges a real pain in the ass.
Oh, and downstream projects aren't forced to use the matching feature branch; they can choose whatever they want, and update as late as they want. And we have to support almost every feature branch from the oldest they use to our latest version. We have three downstream projects, each with vastly different needs. Between this, and all the problems we have with CI, it's no wonder that feature delivery often takes over a week.
-
I call it: "every third-party REST API I've ever had the misfortune of having to integrate with".
Hell, goddamned WebAPI2 does that, and it's from (mostly) Microsoft: "How do you do a file upload in WebAPI?" "You use the multipart/form-data serializer." "There isn't one for WebAPI2." "Right, we haven't bothered making it yet. Older versions have one. But you're fucked." "Thanks." "Have fun going all the way out of our shitty 'complete' framework and having to make a plain ol' ASP.NET .ashx page to handle that."
-
Exhibit A: The Azure Management Portal.
The new portal was in preview for quite some time, then one day Microsoft said "What the hell, just ship the damn thing already!" And it's all shiny and new and works well... right up until you want to do something useful like approve a new API subscriber. You find the API Management option in the menu, select the API you want to manage, and BAM! You're back on the old portal. Which, by the way, says "Hey, why not try out our new portal?" I just came from the new fucking portal!
-
Hey, why not try out our new portal?
Google did that. NFC what's up with companies doing this...
-
How do you call this fairly common anti-pattern?
Jamie Zawinski called it the CADT model, and that's back in 2003.
-
I'd call it the "Waterfall Sewage Dam" anti-pattern.
You get a whole sloshing deluge of undigested shit coming down the sewage pipe. But you can't let it through yet. You want to make sure it all comes out in one big release. So you block everything up. Everyone downstream suffers from lack of resources. Every upstream suffers from an every growing pile of festering, stinking, unusable water. (I may have my up and down streams reversed,
)You won't clean up behind the dam because you're going to release it anyways, eventually. You won't clean up ahead of the damn, because you're just going to release onto it anyways.
Eventually both sides suffer more than they can bear, the dam gives way and bursts a tsunami of shit-laden undrinkable water all over everything, and no one has anything they can use.
-
This post is deleted!
-
@wft said:
How do you call this fairly common anti-pattern?
Jamie Zawinski called it the CADT model, and that's back in 2003.
I dunno, CADT seems to be a sub-pattern of this. CADT, as I understand it, occurs specifically because of A) a regular turn-over of developers (the name comes from the idea of a project in which a series of newly-minted developers picking up an existing project, dropping the existing code base, and re-writing the project from scratch just because they don't have the experience and patience to go through the old code to refactor it), and B) there is more interest in writing new code than in fixing the problems in either the old code or the new version. It is mostly (but not exclusively) an FOSS project anti-pattern, as it is driven mainly by the lack of continuity in the development teams, and is characteriszed by a project that not only fails to fix faults in the earlier version, but by the repetition of older errors over multiple iterations of the same project.
The broader anti-pattern, which might be called "Reinvention Maintenance Corncob" (following the general class of Corncob anti-patterns), comes from various causes, even if the effect - dropping maintenance of the existing code in favor of a massive rewriting process - is similar. In most cases, the solution is to divide the developers into separate maintenance and devellopment teams, break up refactoring processes into smaller teams to avoid the massive re-writes (since no one section can push to re-write the program as a whole), and if possible, put a review process into place to block rewriting projects in favor of refactoring as long as is feasible.
-
Dwarf Fortress avoids this problem by setting 100 long term goals at the start of the project and then having the major version number be 0 and the minor version number be the number of goals met so far.
-
Dwarf Fortress avoids this problem by being so fucking shit no-one cares what version they've just deleted in disgust
Filed under: Post is not can be empty
-
Sounds like vapor powered bugfix freeze to me.
How do I recognize it: I open my development environment.
How do I prevent it: I make a list of all fixes and new features and apply them one after the other to each of the previous versions, trying to break as little as
possiblefeasible within the available timewhatever.How would I recover
ifwhen I find myself in the middle of it: ERR_UNKNOWN_WORD: recover
