I can see that this might be useful in a situation where you're dealing
with a potential customer, and they want to do some some forecasting, but
their needs aren't exactly what your existing system is.
You want to get some idea of how much work it's going to be to
produce a variant for them.
Can we use these specifications to determine that?
>> Yeah, indeed you can.
And in fact, that
exact problem is one of the things that motivated us to invest in this approach.
So, if you look at the slide, you'll see Hello World and
Guten Tag Welt, those two assembly specifications.
And you can notice a couple of things.
First off, they have a lot in common.
So, Guten Tag Welt reuses two of Hello World's components, the bFcst And
mults components and it also uses both of its refinements incr and fcst.
Where they differ is also very clear to see.
So the Hello World has this iFcst and this batch component
where as Guten Tag Welt has the diFcst and batchAdj component.
And Guten Tag Welt has this mods and overrides.
Component interface respectively.
So you can see from this just by comparing exactly
what two variants have in common and exactly how they differ.
>> Okay, Kurt can you tell us something about now that you've
had some experience with using layer blocks over the last year or
so about the benefits you've seen from its use?
>> So, there are several benefits that we can get from it;
the most obvious one is that we get a lot of code reviews.
I can try to quantify that a little bit.
When we had multiple different implementations of these variants and
we replaced them,
which is how we originally brought layer blocks into being.
We replaced them with with a Layer layer blocks based solution,
we've cut our code footprint by about five times.
So, it was a substantial amount of code reduction that we got in [CROSSTALK].
>> You mean 80% in code base?
>> Yeah, that's right.
>> Fantastic.
>> 80% reduction in code base.
In addition, the virtue of it is that it's designed to
do programming by generating variance, rather than writing one off programs.
And so that approach, and that way of doing engineering
actually helps the scale much better to building a large complex software.
It just adds a discipline on it.
Now when developers are working on this code base,
instead of thinking about how to go write the new method or
make this new tweak, they think, could I or should I make this
a different refinement of an existing interface or different feature.
So you get a lot of simplicity in a design by virtue of that.
The scalability of the whole
approach really owes to this idea of feature refinements being so reusable.
As you saw in the examples, and there are many more, each of
those little generators gets reused quite a bit.
So you don't need that many of them, and you can build a pretty interesting and
rich library of variance.
In addition, features, if you design them
by doing a feature analysis are very robust abstractions in a domain, and
so they tend to give you the kind of reuse that we get.
So if you couple a good feature analysis with applying an approach like this,
you're going to have some
good idea that you're going to be able to get this kind of reuse in a project.
And then finally, I think maybe the last big benefit is,
it's really beneficial for understanding and for training.
So if a new developer has to come onto a project, and
they've never see a forecaster before.
But they have an assembly spec which is something that's pretty small,
just a few lines.
And particularly if they see two or three of them for different variants.
They can very quickly get an idea of how to do, a sort of,
top down step wise refinement of a variant as
a sequence of refinements of a very common easy to understand program.
That turns out to have really nice understanding and training benefits.
>> But historically, in software engineering when a code generation
technology or a very general solution to things is proposed, there's often
a performance hit in the generated code that you have to trade off.
Has that been your experience here?
>> So, ironically, it's actually been the opposite.
Let me try to explain why.
So we are doing a lot of generation, you're correct.
But in fact,
because we're generating variants that contain really only what's needed.
They contain only those features and
only those capabilities that are actually needed for
a given variant, and they don't have any extra cruft with them.
They have been running more efficiently.
In fact, when we replaced these hand written forecasters with ones
we generated from this library, we saw pretty dramatic performance improvements
just by reducing the amount of business logic that we had to install into our
database, and which of course then had to always be running and calculating.
So in that case, we've actually seen the opposite.
>> So win win.
>> Win win, yeah.