Refactoring and development economy - was: Re: [sldev] sljirastats.com Linden Metrics Report

[Felix Duesenburg]

Kent Quirk (Q Linden) wrote:
>
> You're proposing the creation of an additional step to the build 
> process, to take something out of data and put it into code. We're 
> moving much more in the direction of moving things out of code and 
> into data. I see that you're trying to draw a bright line between the 
> model and view parts of the UI, and there's a certain argument for 
> your position -- in stable code. But high quality UI development 
> requires lots of iterations. The cycle time for edit/build/test is 
> critical to controlling how many shots you get at making it good. In 
> that scenario, the more you can do in data without a rebuild, the 
> better off you are.
>
> To tie in the other discussion going on right now, we're fully aware 
> that the viewer isn't as modular as anyone would like, and that 
> there's too much coupling between the various pieces. Some of us are 
> working very hard on taking some of that apart right now. I, for 
> example, am one of three developers who have been working on 
> refactoring the notifications and alerts systems, with the help of our 
> UI team and some excellent feedback I got earlier from this list.
>
> We're also doing a lot of work toward making the viewer more and more 
> data-driven. For example, the Notifications system is quite a bit more 
> flexible now, because we're adding capabilities to the XML file we use 
> for localization.
>
> I'm not being authoritarian about this, just trying to express the 
> reality of our goals and that I think they're incompatible with what 
> you're proposing. As far as I can tell, there's little chance that 
> we'll move in favor of moving things into compiled code, especially if 
> doing so also requires adding to build time and complexity.
>
>     Q
>

And these goals are a crucial thing to learn i.o. to reach any degree of 
coherence, thanks for taking the time to clarify. Looking at a mountain 
(workload) and trying to figure out where it makes sense to start 
digging and where there's bedrock under the surface. No point in being 
religious about anything. Still, maybe one more shot at this concrete 
step to "make it compatible", and at the broader strategy:

The cycle time is really a strong argument. What I'm trying to find out 
is, are we compromising in favour of a more economic development 
process, or is a strict separation as taught in the MVC philosophy not 
seen as that important when talking about refactoring? If the former is 
the case, there is certainly headroom for improving on what was 
previously said.

A compromise could be to switch on the custom build step only for 
shelling out a new release viewer, and to leave it out while GUI 
elements are being developed. I don't foresee a lot of problems/bugs 
that could occur only because of that step, because once established it 
runs automatic, same as with Bison for the script compiler. I find it 
hard to imagine that anyone would prefer to have that ditched as well 
for a data driven approach? Although this would enable the possibility 
to hook up any programming language with the script engine by finding a 
way to describe how it is to be translated into bytecode (current or 
mono). No need to recompile... hmmm, /scratching my head if someone 
would like to have this, or rather drill a hole into their kneecap than 
adding such complexity...

The main point of this now is to shed light on the distinction between 
what is/should be flexible for the developer for reaching a better work 
economy, and what is/should be mutable/immutable to the end user or 
"light developer" (i.e. skinning, customizing the surface only). I don't 
think there's an argument that there has to be a certain core which the 
user is not to touch, and that strictly ought to be developed with the 
goal of stability. What exactly that core comprises is a subject of 
discussion and needs to be clearly defined. So I'm wondering if maybe a 
design paper already exists that is a bit more concrete than just saying 
"we're moving towards a more data-driven approach"? Call me donkey if I 
missed a wiki on that. Is anyone possibly thinking of a client/server 
architecture in the fashion of the X window system under Linux?

By the way, when starting this I didn't really think of the GUI 
initially, and didn't mean to focus on it either. I took my first stab 
at the LSL parser and was dealing with keywords.ini there. If I had my 
way I'd shoot it and write the definitions into a header, because the 
actual collection of keywords and their function in LSL is immutable 
outside of development. (I'm contradicting myself with the loadable 
bytecode compiler mention above, but that would be a thing of the future 
if at all.) Customizable are the colours for the categories in syntax 
highlighting, and of course the tooltips that could be translated into 
other languages, so those should be going into XML somewhere. As it is, 
this flexibility does not exist anyway, and maybe there are similar 
situations in other parts of the application. Would that be seen as a 
small but worthwhile task in the bigger picture?

Forgive me if I perceive the criticism of "adding complexity" as a 
little political in this context... every time a new big feature is 
introduced, it adds a lot more complexity than what we're talking about 
here :)

Felix