Had a frustrating conversation with a friend about this. His comment was that one of the things that attracted him to his field is the lack of care in presentation. It’s “all about the science” and that a put together talk or paper is often masking some sort of problem with the facts.

It confirmed that I shouldn’t be allowed to get within 20 feet of academia.

On Book Design is going into the queue.

“Being Welcoming to Outsiders”

Perhaps this is so general as to be useless. I don’t know.

[1] http://plus.google.com/110440139189906861022/posts/7zzuKSoR838
[2] http://michaelochurch.wordpress.com/2012/08/15/what-is-spaghetti-code/#comment-836

For people who are technically competent software developers—that is, those who understand how and why to make the extra effort to produce clean code, the message is: GP is a prosthesis for accelerating generative projects. It can speed up the (human) discovery of novel solutions—but only does this reproducibly in the context of serious and active domain modeling, constant introspection and refactoring, and an essentially humane view of the project.

For people raised in the tradition that GP is in some sense “strong AI”, self-contained thinking-in-a-box: good luck with that.

So it may well be that there’s a missing bit of theory about the nature of the research program, as you say. But after twenty years’ time working with GP pretty much constantly, I’m willing to go out on an limb and say the “missing theory” has a lot more to do with poor self-definition and foolish habits among practitioners than it does with “science”.

Thus, what I’m saying in the book is aimed at people who ship working software, and I hope it doesn’t interfere at all with Computer Scientists’ plans to Explain Everything and How It Ought to Be in the Future. Because I’d love to hear what the future is supposed to have been, while the rest of us have been solving problems and doing work and stuff.

Interesting .…er stance.

I happen to think that the problem with GP (and other areas of EC) runs deeper; that folks are trying to construct better combustion engines while adhering to the phlogiston theory of combustion.

This is not to belittle the social aspects of engineering, but to say that the time to address those aspects is after the science has been worked out. Evolutionary Computation’s real problem is the poor quality of the science at its foundations. The field wants for scientists (not to be confused with “theorists”, of which there are plenty).

So you’re writing a book on GP. At some point you’ll presumably tell your readers how GP works. (Not to put you on the spot, but … ) What will you say?

I’m a graphic designer and expect a minimum of performance from the hard/software I use. I only want to scan 600dpi large grey or color tiffs, raw material for the work I’m doing. The scans Ive been getting are tiffs with jpeg compression (never saw these before). ever hear of lossy compression? the results are abysmal. a small $60 canon gives me a better image. Workaround suggested by the tech was to scan to image folio as bmp’s. If that worked it could be ok, however greyscale images are converted to index color.

Tried to upgrade the driver and what it did was uninstall the older one and not install anything.

Running the twain through ps may work but you’d have to relaunch it for every scan, negating any speed. A pain when you scanning 2–500 images. Going to install the 4800 driver on the mac to see if it will run.

As a special feature, I’ve been getting streaks and flares in the scans whenever I pause the work for more than a few minutes. only solution is to shut everything down, wait and start again. trying to get plustek to fix this.
Overall, a lousy product and one to avoid. My apologies if I sound like I’m ranting. I’m just very frustrated having invested in a product that can’t deliver simple basics and a company that doesn’t seem to be able to address their issues.

The change I had in mind was one of several I ended up making of course, but the one in question was that I added the capacity of the Duck interpreter to reuse code. Basically there are a number of commands in the language (now) that move chunks of the script onto the stack as code, where it can subsequently be duplicated, recombined with other code, assigned as the value of a variable, and (obviously) re-executed. That was the one I was talking about, and it worked for what it was intended to do: add simple recursion.

I knew it was working as intended the first time a random program copied a block of code over to the stack, bound it to a variable, and then called it… and the code in question had the variable call itself in it. Infinite loop = winning, at least by this criterion.

Since then, there have been a bunch more traditional non-reductive extensions as well; Iterators, Enumerators, Ranges, and of course in the current Duck interpreter the Interpreter can spawn other Interpreter objects.

Which is where you remind me that the documentation isn’t up to date, and I say “Yes, you’re right!”

But I can save 700-dpi scans of 11″×17″ pages, in color. So the truce muddles on.

I expect Plustek manages because the next-cheapest scanner capable of that is well over $10000, last I checked.

I had originally intended to model these functionalities as essentially optimal to begin with, and permit perfect transfer of information between them in both project structures (one-cycle, many-cycle). And then later add in some realistic inefficiencies, like bounded rationality, inertia in learning or just-plain-errors.

But it sounds as if you both really want the actions of Analysis (“requirements-gathering”) and Coding (“implementation”) to start off as the subject of our storytelling, rather than being a mere control parameter as I’d considered. Can do.

I’m not totally sure there’s an “of course” about that — I tend to treat these activities more as sense-making devices than as the One True way to carve the nature of software development at its joints. But that shouldn’t be a problem for this conversation.

I’ll spend a bit of time this afternoon and fill in the “tbd” parts of my sketchy précis. In particular, what “requirements”, “design”, “implementation”, “verification” and “maintenance” might be.

We’ll see if we can still come to an agreement about what’s of interest, since as you say Laurent, I was starting with the premise that we’re talking about a difference between institutions, and that all externalities (the Market) are simply received information about some abstract process outside. The comparison I’m heading towards comes out of a chat with Ron the other day, where he reminded me that of course “analysis”, “design”, “coding”, “testing” and that other one are all present in both institutional models; just that the criteria and responsibility for moving from one to another are different.

As a preview-ish thing, what I was considering was that a “unit” of “requirements/analysis” might involve looking at the historical data for one feature in The Market, and building a statistical regression model, say a simple random forest or CART tree—something that would predict the future of that feature, but not in a useful format (since our Team isn’t building statistical models, it’s building Boolean Networks).

“Design” would involve translating the model (of one or a few features) into a Boolean network template; “implementation” would be a time-consuming matter of “simply” filling out the values in the tables; “testing” would be comparing the more recent Market behavior to the output of the code, and “maintenance” would red-flag features as “re-work” if the errors passed a certain threshold.

Now I can see a couple of places where your interest in the localization of skills (in “analysts” or “coders”) might slot in there.

My goal, though, is simply to deliver a model that if you squint is able to perform as a “waterfall” or an “agile” team, and which has plenty of places for errors, risks and such to be explored after a “perfect” version is written.

… it seems to me that an important issue is how many of the Answers wind up in the Programmer’s head, because only the Programmer builds the program, and it will have nothing in it that was not in the Programmer’s head.

So if the Analyst gets X% of the Answers when he works alone, and the Programmer gets Y%, Y probably < X, and then the Analyst communicates the Answers to the Programmer, who then gets f(X) answers, where f is some function with range 0 <= f <= 1, we can model and experiment with the notion of hand-off. And if we put the Programmer in the room while the Analyst Questions, the Programmer will hear both the Questions and the Answers. She may get them better having heard them first hand, which we can model. And there’s more! She may even ask Questions of her own, since she is now in a conversation that has removed much of the discomfort, and we can model her different (and in some ways better for the implementation) Questions and her better apprehension of Answers she cares about.

Perhaps that makes sense. I know it interests me.

For instance I immediately started wondering how one might transpose the two Agile practices that are currently topmost in my mind at the moment (for contingent reasons) into this model’s terms: Simple Design, aka YAGNI, and signing up for tasks.

The latter is interesting, insofar as it relies on “the knowledge that one kind of agent has about other agents”, at least if you want to model the pre-Agile approach to project management, where the PM is the one expected to parcel out tasks to developers. (In many of the places where I worked pre-Agile this was in fact one of the PM’s major prerogatives, and to question it would have been politically unthinkable.)

As for YAGNI, the properties of NK networks are obviously applicable directly — many local optima and short hill-climbs, directly leading to the often-discussed problem of “planning ahead” in software design.

I’m also kind of surprised at where you’ve placed the emphasis in your modeling effort: The Market, a large aggregate of people external to the small aggregate of people who are actually directly involved in writing the software. I might have started with The Customer. Then again, perhaps we’d end up in the same place, since The Customer can often be modeled as an aggregate of conflicting desires, not totally unlike an aggregate of many people.

One of the differences of interest in Agile vs. “plan driven” (for lack of a better term, but I’d rather use a phrase more constructive than “non-Agile”) is the differing focus on specialization and boundaries.

In plan-driven work, more of the “requirements” work consists of having Analysts talking to Customers, where Analysts are agents whose toolkit does not include “Coding”, but does include “Questioning”. You could model “Questioning” as an activity that yields some amount of information about The Market (or about The Customer’s understanding of The Market). Only when the Questioning starts to converge on a stable set of answers do these projects move on to the implementation phase, which is taken over by Developers who have Coding in their toolkit but not Questioning (or have it but have a high cost imposed on them for using it, etc.).

In Agile work, both Questioning and Coding yield information, Developers are expected to have both in their toolkit, and to engage in both. Coding additionally yields information about the “internal” fitness landscape of the product, *and* is a noisy generator of that same internal fitness landscape. What kind of Developer works on what kind of technical task is part of the sources of noise. A potential downside is that the Customer is now playing an active role throughout, with Coding having an impact on how they respond to Questioning.

To me, the kind of model you seem to be proposing are valuable insofar as they provide a way to “mimic” the *differences* between these approaches. Agent-based seems like a potential good fit because I can express policies like YAGNI or incremental construction, vs. speculative design or sequential phases, in terms of algorithms, of explicit policies (a.k.a. “process”).

The downside is that the model must, up-front, provide a rich enough ontology that these algorithms will say something meaningful, and that was the barrier I hit.

I’m curious to see where you’re going; I promise to jump in and start writing code (“you had me at .rb”) as soon as I see a way to express the distinctions I’m interested in.

I feel fairly comfortable with contingency — the idea that just setting the right policies may not deterministically lead to the outcomes I expect, that things like butterfly effects might come into play. I feel fairly comfortable with subjectivity — the idea that the model by itself *proves nothing* about Agile one way or another, and that after seeing how the models turn out I still have to do all of the hard work of thinking about my own situation and taking decisions I will be accountable for.

The story telling aspect of this is the interesting part, because inevitably things get simplified down when things are complex.

The world I live in at the moment has failures from time to time within a System, and so there’s a set of narratives that get constructed about each of these. Inevitably the user perspective on the System is somewhat abstract, so you don’t want your story about what went wrong with the System to be so full of sharp pointy edges that people lose confidence in its abstract beauty. Yet the developers of the System know all too well, or need to be reminded from time to time, that there are indeed sharp pointy edges and that you can’t always do everything in a way that looks like the obvious way to do it.

The perpetual challenge is to tell a story that is simplified enough to make sense to the user, but not so oversimplified that the system builder doesn’t recognize it.

I’m sure that your correspondents simply want you to tell them a story that doesn’t require that you invoke magic to explain it; or, if there really is magic going on deep inside, that it gets hidden enough with soothing words that sound like you are describing something non-magical (at least from the outside).

One useful simplification with a lot of philosophical weight might be to represent the project as a model of some complex and dynamic externality. The “customer” (read: “business”) would want to minimize the errors in their complex model of the world at the point where the model is put into production, and would only get value based on the amount of the business world’s environment it manages to capture.

So for example, consider the world is “really” some function , where it depends on some variables at time .

A “waterfall” project would spend time collecting a whole bunch of data, and modeling the entirety of the “world function”, and then produce a requirements document which would be implemented. Suppose the development team takes a simulated week for every “quantum” of the model to be implemented, and the testing team takes a simulated week for every “quantum” of the model to be tested, when does business value get delivered to the customer?

An “agile” project might spend less time collecting data, and would begin by providing the single “quantum” of model which returned the most value to the customer as soon as possible. For example, it might return the average of the last three values seen, which would be better than nothing, and then work on subsequent weeks on trying to improve the approximation of the “world model” greedily, without losing any accuracy in something already explained.

Anyway, that’s my sketch. One would need to consider what a “quantum” of modeling is: maybe a certain amount of accuracy on one test case, or something? If the “world model” is so complicated that it would defy the toolkit available to either group (say it depends on unmeasured externalities, or noise, or changes over time, or is affected by the progress made by the “development process” itself, or any other realistic driver), then the comparison between early delivery of partial results vs. delayed delivery of rational results would be pretty straightforward.

I’d start trying to model as closely as possible the assumptions embodied in the “waterfall” approach, then question my model from an Agile POV, looking for reasons why this model *couldn’t possibly be* the whole story.

For instance, I’d model a project as 100 “chunks” of value from a software project, and assume that these 100 chunks started out as being of the Specified type, and could be transformed without error into 100 chunks of the Designed type, then into 100 chunks of the Coded type, then into 100 of the Tested type, and so on.

There would be no error at any step along the way, and each transformation would be fully deterministic.

Given these assumptions it’s clear that Waterfall “always works”, and it’s an observational fact that Waterfall doesn’t in fact “always work”, so I’d go looking for which assumption didn’t reflect reality.

So, for instance, I’d set a probability p that a Coded chunk had an error, and the testing step would return it to the Coded state instead of advancing it to Tested. You’d need to iterate the testing step until you had 100% of the project value.

What do you know, Waterfall *still* always works under these assumptions.

So I’d have to introduce still more realistic elements: for instance distinguish the chunks and introduce a sequence of dependency, so that an undetected error in one of the chunks could propagate to chunks that depended on it.

The problem is that by that point I felt like an explosion in model complexity was inevitable, and didn’t know how to deal with it. Even this small assumption of dependencies between chunks can be implemented in any number of different ways, with no good reason to pick one over the other. Similarly how errors caused further errors seemed like a huge can of worms to open.

It felt to me as if this one thing, the “problem of quality” or the “problem of errors” played a major role in “Agile vs what came before” (insofar as that comparison made any sense). But it was also a scary problem, and I think the truth is that I retreated from approaching it, at least with simulation as an instrument of exploration.

You should add that warning to the comment form for Notional Slurry.