Jeroen De Dauw schreef op 2014/11/09 0:29:
Hey,
I suspect it isn't done because it isn't a very good way to modify a
complex embedded base of software, Lila. Generally, when modifying a complex embedded base, one designs first, iterates implementation and internal testing, and then releases a relatively complete piece of functionality.
As far as I understand this is about adding a new service, not modifying complex existing behaviour. Is that wrong?
Also, while I can't speak for Lila, it does seem to me she is suggesting to go with a simple solution that tackles a specific need well, as opposed to releasing something incomplete. The idea to build small dedicated units rather than monoliths is not something new or controversial in the world of software design. Even though it might be in certain insular communities.
Her comment included
1. As an editor I'd like to flag a revision as reviewed/verified by me from the revision screen or list. 2. As an editor I want to see which revisions were verified/had second opinion by other editors.
That's not a "service" by any definition I'm aware of, that's a user interaction, one that seems to presume the existence of the Wikimedia base.
There's no doubt that there's a lot of leeway in terms of how much one implements in each release of software, but one should always have a reasonably clear image of the final target, know where the piece being implemented now fits into the final result, and take steps to ensure that each release is sufficiently complete to be useful. There have been some successful products built using the "code first, design later" method, but that doesn't mean it should be encouraged. Even SCRUM encourages you to have some idea of what the final result will be, even if each phase is scoped opportunistically.
KWW