[Bf-committers] Understanding the dev process

[Julian Eisel]

The following is a bit of a résumé on the 2.8 project from my POV. There are
many lessons to be learned from it I think.

Am Fr., 5. Juli 2019 um 16:54 Uhr schrieb Brecht Van Lommel <brechtvanlommel
@gmail.com>:

> I think the main issue recently was that for the first half of the 2.8
> project, many changes were made without well-defined use cases and
> design, and much code was left incomplete or broken. This left the
> second half of the project with the difficult task of solving much
> technical debt, with little time left for anything else.
>

I definitely agree on the issue of technical debt, not so much on missing
use
cases and design. At least for the projects I was involved in (includes
projects
run by others where I helped with feedback/advice), lots of effort was put
into
requirements, specification and design considerations. Dalai and Ton were
really
pushy on that. IMHO the issue is that some of these designs didn't work
well in
practise.

In the first half, many bigger projects were tackled, and I think those are
the ones
causing problems now. They kept dragging on for long periods. Many of them
were 'big picture' ones and depended on other projects to reach full
potential
(layers, collections, workspaces, workflow oriented viewports, etc.). I
guess the
whole "workflow" thing was a huge beast but lacking user involvement. Not
saying there wasn't any, but not in a broader sense.
At the time, to the "outside world" 2.8 apparently seemed like Eevee + some
other WIP stuff nobody understands or uses yet. Despite efforts to
communicate
designs well.
There was a big lack of user feedback. Designs looked awesome on paper (at
least to some), but turned out to be faulty later. It's selfish to say so,
but I saw
this coming. The first half of the 2.8 project, I wasn't at all happy with
the direction it was taking.
For me the Code Quest + usage of 2.8 in Spring production was the turning
point,
marking the second half of the 2.8 project. Suddenly the project turned
into a
hugely dynamic one with very visible results. Users became part of the
development loop. We went back to what has always worked best for Blender.
However, there was so much dynamics, that I'm afraid we'll find lots of
longer term
technical debt from it too. There's always a trade off, although I think it
is worth it
in this case.

Another issue is devs losing motivation after projects dragged on with
mentioned
issues. Maybe this is mostly about me again - for many reasons (not being
able
to push 2.8 into a for my opinion better direction was a big part of it) I
lost
motivation and eventually left the project. And with that I also left big
technical
debt...
With long iteration loops we run into the risk of this happening more.


> We plan to go to an iterative approach with regular releases, and it's
> not easy to predict how that will go after two years of a different
> model. There is a risk of getting bogged down in bug fixing and small
> changes, without time or confidence to finish bigger things.
>

> Developers should be given time to tackle those bigger projects and
> refactors. On the other hand, those projects then also have to be done
> in a more disciplined way. That means splitting up projects into
> smaller steps. Fully going through the design, implementation,
> stabilization and documentation for each step. Developers should be
> encouraged to pace themselves so they can take the time to do projects
> well, but at the same time keep delivering finished steps even if they
> are small, and getting user feedback early.
>

I guess the big lesson to be learned from all this is how important short
iteration
loops are. Get visible results quickly, get user feedback and keep
evaluating and
adjusting requirements, specifications and designs. But don't neglect the
code
quality (too much), that'll slow you down later. Short release cycles
enforce this
a bit so I like the idea of getting back to them. But indeed, we need these
timeouts to work on big projects. Those can be developed in short iteration
cycles as well though.
In other words: We need more Scrum. Not a business variant for
micromanagement and short term success, but what it was initially created
for:
A framework for developers to manage themselves for both short and long term
agility.

I didn't go into other aspects yet, like developer documentation or review
process.
Would be happy to cover this with a bit more time at hand ;)

Glad there's someone asking for feeback on the dev process!


> I have a document with more practical suggestions here:
>
> https://docs.google.com/document/d/1gxuBv6aeZjKgzMQmGYdaERKbd7VnllSa9s_ejl2hMGo/
>
>
>
>
>
>
>
>
>
>
> On Thu, Jul 4, 2019 at 3:38 PM Nathan Letwory <jesterking at letwory.net>
> wrote:
> >
> > Hey all,
> >
> > As you all may know by now I've been asked to help coordinate and manage
> > the Blender development.
> >
> > To get a better understanding of what these days is going on, and to
> > prevent me from just acting through my personal preferences, I'd like to
> > hear from the blender developer community how they see the current dev
> > process.
> >
> > I'm most interested in finding out how devs perceive the process: what
> goes
> > well, and even more so what causes trouble.
> >
> > An open discussion by anyone on this topic is of course welcome, but I'd
> > like (and also a bit expect) input at least from those who are listed on
> > the Modules [1] page.
> >
> > Cheers!
> >
> > /Nathan 'jesterKing' Letwory
> >
> >   [1] https://wiki.blender.org/wiki/Modules
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>