launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

On Wed, Feb 1, 2012 at 3:32 AM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
> Hi, please glance at https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts
>
> The basic idea is that we are where we are today because we didn't at
> any point put a cap on the overheads involved in maintaining
> Launchpad. The ratio of developer time that goes into maintenance vs
> delivering new functionality is quite high, and if it continues to
> grow we may never climb out of the technical-debt hole that we have.
>

I very strongly agree with the general principle, heartily endorse the
item you added to the ReadyToCode wiki page and think the policy is
heading in the right direction.

The policy document as written wouldn't help me think about the
ongoing maintenance cost of a proposed change. The list of "What
things increase cost" is a true one, but sometimes requires knowledge
of the future. A simple rule would be nice, but you're right that it
would be hard to come up with one.

As Martin says, examples could help. Another thing could be rephrasing
the items as thought-provoking questions: Does it add extra steps to
an existing process? Does it add code?

You could also do what Drizzle did and make a rule that we all know is
arbitrary and not entirely correct but is certainly easy to follow.
This would be a fitting break from the Launchpad (as-a-product)
tradition of covering every imaginable use case.

Another idea would be to make the policy even stronger. Say that from
now patches must reduce maintenance cost, and specify what that might
mean: make LP faster, make dev cycle faster, remove code, remove the
need for documentation, increase architectural transparency etc.

Still another idea would be to compel everyone to watch Rich Hickey's
excellent talk that Gary shared months ago[1], and replace the entire
policy with "make things simpler".

On another note, now that I'm not working on the Launchpad team, it's
even more obvious to me that you guys are tackling some really
interesting and deep problems and making some really good progress.
There's a lot that you could teach other teams in Canonical and the
world in general. If you don't get around to pimping yourselves more,
I'm going to start stealing your ideas and make myself look heaps
smarter than I actually am.

jml

[1] http://www.infoq.com/presentations/Simple-Made-Easy