BTW, does he have to take into account the customers who do not see a barber and walk away? That was very funny!!

posted by pierreleclercq

posted by pierreleclercq

posted by pierreleclercq

posted by pierreleclercq

posted by pierreleclercq

posted by pierreleclercq

raymond wrote:



pierreleclercq wrote:  raymond wrote:  Be careful, Charles the Hammer does not allow posts on religious subjects. He will lock them. Hmm... religious subjects.... You must be talking about this "churn" thing?

Churn is not a religious issue with me.

I keep hearing the word churn from  current and retired Microsoft developers.

For example, see a great video interview with Jason Zander on the various versions of the .NET Framework. He uses the word churn.

I work in an Microsoft based enterprise shop that has its own ERP application and churn is an issue.

However, for my own moon-lighting work, I need both .NET 3.0 and 3.5 or 4.0, Expression, and Visual Studio 2007 ASAP.

I liked your photos!

 

posted by pierreleclercq

posted by pierreleclercq

posted by pierreleclercq

Isn't it cute?

My opinion is I "massively" love those beauties.
It takes an average 3 centuries for this type of work,
so the people who started this did not get a chance
to see it done. For sure, no one could have claimed
ownership of the job...


I wonder how a gantt diagram would have looked
for this project, had it been invented

posted by pierreleclercq

Speaking of both concurrency and formal composition, one could remember
ACTOR's models, and how neat clean and simple they were. Everything is an
actor and then you build upon this. But for real applications this model
was a little hard to use without a few changes. Even LISP the language were
affectation was not supposed to be used, eventually introduced the setq syntax.

The DNA architecture introduced a very sexy way of looking at software systems.
Let's get some inspiration from biological systems. When a stimulus comes in
it is normally processed through the central nervous system. This central system
built using formal composition encompasses layers and layers of data processing.
This takes a while to be processed, and when the response is ready, the biological
system has to hope the environment has not changed too much. Some dinosaurs, cold
blooded could have a small beast feed on their tail, as it would take about a minute
for the nervous influx to propagate to the central brain. So some of those dinosaurs
developed an intermediate brain at the bottom of their back that would preprocess
incoming data, and, for example, would order a 'shake tail' when a bite feeling was
coming in.
Our brain also has some similar mechanisms, when some unrecognized pattern comes in
it is processed by higher level, and slow (and much layered) parts of the brain. If
an answer is found, and this pattern shows up several times, a couple stimulus / reflex
is stored in the reptilian brain.

I am a big fan of the dotnet framework, and started using it a soon as it became
commercially available. But at the beginning, a few thing looked strange, until
I figured out the whole framework was another layer on top of a number of existing ones.

The feeling I have today is after having been a regular C-style procedural type of culture,
at MS, some kind of internal revolution occured driven by academical formal approaches.
I would be the first to salute this switch, and understand why this is happening, but
I'd remain cautious about how some steps could have been ignored, and would not forget
MS is building real-world applications, not academical try outs.

posted by pierreleclercq

Let's acknowledge the fact a pipeline model, although useful, and simple, does not necessarily provide the most extensive ways to find innovative ideas and turn them into products.

Great products are often built on an initial good idea, but require constant seeding to keep evolving. A lot of input comes from marketing feed, and it is necessary. On the other hand product development, in itself, generates a lot of side technology which is usually not exploited due to time/budget constraints, and simple irrelevance to the priorities at hand.

Research is not necessarily product driven, and the goal are more about developing concepts and building proof of concepts.

The classical pipeline model usually relies on hypothetical communication between those two layers, each with distinct goals. The idea would be to come up with an organization that would provide a tighter integration, in order to not only feed research into development, but also feed back some development ideas into research.

The process would be split into three different teams. The first team would look like a conventional research team, in charge of exploring ideas, and building proof of concepts. The second team would look like a product team, but on a lightweight scale. It would monitor the work of the research team, and identify meaningful ideas they will productize. As a lightweight development team, it will follow a development process, where the goal would not be to actually kick something out the door, but rather to provide development-oriented insights that will be fed back into the research team. Just as in a neural net, you would then witness an exploration process where convergence is driven by a feedback loop. The third team would have the goal of monitoring the two other teams, possibly providing some higher level feedback, but most importantly identifying short term products and feeding them into the marketing and engineering teams. Another goal for this team could be to facilitate technology transfers between this organization and engineering.

As a whole those three teams would remain a research organization, but could provide a strong interleave of engineering and research skills and knowledge.

One could question the amount of resources needed for funding such an organization, which is, in itself, an organizational research project, but the pipeline model although simple has shown limits. It would be easy to name large companies which have faced the situation where despite having funded massive research efforts, and actually having found great concepts, never turned them into real-life products. Then, the amount of resources used is quite large, even for a pipeline model.

Pierre Leclercq

posted by pierreleclercq

posted by pierreleclercq

posted by pierreleclercq

I am curious of how the C# team will face the challenge of
a growing language. Someone in the assistance mentionned
the creeping of functionnal programming inside C#. For example,
LISP initially designed to be very simple and homogeneous,
has then evolved into a 1200 pages standard. And this standard,
besides being "functional-oriented", had imperative constructs,
and object oriented constructs. C++ starting from its low-level
origins also has grown into a thousand pages standard.
The C# team actually did a great job at designing a homogeneous
language, but the idea of providing one path for one problem
will have a hard time living through the growth of the language.
As eventually there always comes a situation where the programmer
needs freedom, the choice might be between spawning new simple
languages, or keeping on growing. So far the number of available
languages, only for MS gives a clue of the extent of the problem.
(And this is not a negative comment).
Back in the early 80's the DOD realized they had tens of programming
languages being used internally, so they decided to come up
with a unification aka ADA. But that did not remove the need for
various types of languages. In the 60's AI was supposed to be
implemented before the end of the century. And declarative programming
has been a promise since the 40's.
I think the advances with XML are really great, but as someone wrote in
another post, it might be a good idea to have a declarative layer,
and an imperative/object oriented layer.
So hurry slowly toward fully declarative languages.

Also there is much greatness in .net. Although C# and .net are tightly
coupled, programming for .net provides a very homogeneous set of
programming experiences for all the supported languages. This
factorization favors improvements across a variety of languages,
each with its own flavor, but iteratively improving each others.
Looks like a powerful leverage for evolution...
(And still providing lots of freedom for specific classes of problems)

This eco-system oriented growth of the languages is IMHO something
where Java definitely fell short... Well I mean the initial idea,
as there is a J#.net

As Anders said: Keep inventing...

posted by pierreleclercq

posted by pierreleclercq