On Mon, Aug 10, 2015 at 10:44 AM, Katie Horn <[email protected]> wrote: > > I think we can safely assume that any team that relies on any kind of third > party integration for one or more of their features to continue working, > will have some degree of the same situation.
I think I'd agree and then point out that MediaWiki is a 3rd party integration for most teams. I say that because with multiple teams plus the FLOSS development community working on MediaWiki all of the time there are bound to be changes to the shared software product that propagate back up to other teams. In the most perfect scenario this propagation comes mostly in the form of gerrit code reviews submitted by the team/developer changing core because they have done the leg work and figured out that extensions X, Y and Z will need to change. This perfect world scenario is relatively rare however. It is more likely that a subtle change in the shared code breaks something in an extension maintained by the team and needs to be addressed. I think I would personally invert Kevin's assertion and say that most teams are (or should be) spending a non-trivial amount of time performing both maintenance and responsive correction work. Hopefully this doesn't rise above a reasonable threshold (say 30%) of the full team capacity, but it really would always be there. When you code to a platform that is as large and widely used as MediaWiki this is just the cost of doing business. Most teams are not startups playing in a green field. They are rather maintainers of software used by millions on a daily basis in a complex ecosystem of shared responsibility. This "burden" is not unique to the WMF or FLOSS systems. This is one of the reasons that a typical software development organization with stable funding grows its developer team at a fairly constant rate. That head count growth doesn't go into acceleration of new development; it is instead used to offset the constantly increasing maintenance cost of running a successful software product. Seat of the pants heuristics for calculating this cost vary by company for a large variety of reasons, but I have personally never been anywhere where this cost was less than 30% per year. In this example, if you have 10 engineers in year 0 you will need to grow to 13 engineers in year 1 to maintain an equivalent capacity to enhance the product. The 3 additional engineer years of capacity will be consumed by maintenance, testing and communication overhead. This progression (10, 13, 17, 22, 29, 35, ...) continues indefinitely and can only really be halted by halting the product. It is conceptually possible that any given team can ignore this reality and focus on "cranking out new code", but the organization can't and will have to adjust to provide the additional capacity by other means. Bryan -- Bryan Davis Wikimedia Foundation <[email protected]> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855 _______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
