[teampractices] "Maintenance" vs "New work"

[Bryan Davis]

On Mon, Aug 10, 2015 at 10:44 AM, Katie Horn <khorn at wikimedia.org> 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    <bd808 at wikimedia.org>
[[m:User:BDavis_(WMF)]]  Sr Software Engineer            Boise, ID USA
irc: bd808                                        v:415.839.6885 x6855