Open Stack

In the rather long history of OpenStack there have been plenty of
discussions about how to make sure that architectural and code
complexity and various forms technical debt get the attention they
deserve. Lots of different approaches from different angles; some
more successful than others. One recent not-so-successful effort was
the architecture working group: it never got enough traction to make
any real change.

In TC office hours earlier this week

    http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-08-22.log.html#t2017-08-22T09:02:42

I introduced an idea for a different approach: attempt to reduce
some measure of complexity by prioritizing simple rules of thumb
about code complexity: "things like extracing methods, keeping
methods short, avoiding side effects, keeping modules short".

To make this discussion more concrete I've proposed that we "Add
Reduce Development Complexity" to the top-5 help wanted list:

     https://review.openstack.org/#/c/496404/

(The top-5 list

     https://governance.openstack.org/tc/reference/top-5-help-wanted.html

is a way to socialize and popularize areas where additional
contribution and attention is needed.)

This idea could just as easily be a community goal, or something we
take on simply because we are motivated folk. I'm simply using the
review as a way to get the conversation started and bound it a bit
so we don't fall in a hole. It may be that this goes nowhere, but
it's worth a try.

Different people have very different ideas on what complexity in
code means, and the relative important of maintainability and
readability. In the document under review I state some of the
reasons why these things might be important for than just personal
preference reasons. It also includes some complexity stats[1] for some
of the larger and older projects.

If you have thoughts on this idea, please comment here or on the
review, especially if you have some ideas on how to make issues like
this have traction.

Thanks.

[1] Note that such metrics are not substitute for human evaluation
of code. They simply provide a straightforward way of finding some
sore thumbs. We should neither trust nor rely on these metrics to
assert much of anything.

-- 
Chris Dent                      (⊙＿⊙')         https://anticdent.org/
freenode: cdent                                         tw: @anticdent