The Blob Report

Index

1. Introduction
2. The options
3. Discussion of the options
4. Summary
5. Conclusion

1. Introduction

   Recently I've looked at the "Blob" code, in order to see how best Cefn and I can combine our efforts, and work together.

   I have not been very impressed.

   The code appears to have minimal functionality, and poor performance.

   Essentially, it sits there for a short while displaying ten static creatures consisting of what appear to be up to three rods. Occasionally two of the rods are joined together [Cefn has since updated the code and this description is no longer precisely accurate].

   Essentially, the code does nothing. It is extremely non-functional. Perhaps the best way to see this is to try it yourself [the code now behaves differently - and these days the creatures reproduce.]

   Because the code does so little, I have had to easing the code, and its javadoc documentation in some depth in order to evaluate the code.

   After a sufficiently comprehensive study, I have racked my brain trying to think of a way to incorporate this code into my vision of the project - with very little success.

2. The options

   Here are the main options as I see them:
   1. The "Blob" codebase is regarded as irrelevant to the project, at least in the short term;
   2. Cefn strips off his display code, and use his genetics to build creatures which interact with my physics simulator, using the third party interface;
   3. Cefn attempts to contribute to my codebase;
   4. We continue to work on our projects independently.
   5. I strip off Cefn's display code, and use his genetics to build creatures which interact with my physics simulator;
   6. The "Blob" codebase is used as a basis for the project, with me making attempts to reuse my existing code in its development;

3. Discussion of the options

   1. The "Blob" codebase is regarded as irrelevant to the project [...] - in the absence of any real knowledge of the "Blob" code (until yesterday), this has been my provisional working hypothesis. The situation seems to be quite a lot worse than I had imagined.

      Under this option, Cefn would be advised to work on other bits of the project.

   2. Cefn [assists me] - as an alternative to option 3 one possibility would be for Cefn to work with me, on my codebase.

      This has an advantage over option 3 (in my book) in that - in my opinion - it increases the chance of Cefn's code being used, and effectively stops us from uselessly duplicating one another's work.

      However, there are disadvantages: I'll probably have to spend a fair quantity of time documenting my code, explaining to Cefn what I think needs to be done and helping him do it. It will probably take a month or so to reach break "even point", a state is reached where Cefn is able to make contributions at a reasonable rate, and compensate for the efforts on my part to help him work with my code.

      Another disadvantage is that I doubt Cefn will be terribly happy with this plan. It may be better to make sure he's a happy worker than to go down this route.

   3. Cefn [interfaces his code to my physics engine] - Cefn's probably in a slightly better position than me to do this, since my code has a documented API designed for this purpose. This is a way the Cefn can still do something that might be of use (given my perspective on the project).

      My concern about this is that in order to best serve his needs, I would need to significantly flesh out the existing interface third party interface and its documentation - providing event listeners, and probably a lot more "neighbourhood sensing" methods than are currently present.

      This could be a time-consuming task. I'd like to see some evidence that the code I'm interfacing has some chance of actually doing something before I spend much more time on the external interface.

   4. We continue to work on our projects independently - and design different species of creatures.

      Our clients get run on separate machines, do their own thing, and contribute independently to the renderer.

      This is what the current situation looks like to me. I doubt continuing along these lines is a good idea. It seems likey that one project would eventually wind up being much better than the other one. Since one project seems desitined to get ditched, investment of resources into a dual development process makes little sense. Justification for it might involve:

      • Not putting all the eggs into one basket
      - having the project dependent on one individual is inadvisable. Also, if you can afford to have two baskets, the chances of one of them containing golden eggs is increased.
      • Cultivating competitive spirit;

      Competitive spirit has its place. Within a single organisation that is capable of managing itself, competition is often known as "internal friction" and "pointless duplication of effort".

      The time for abandoning flirting with independent codebases seems to me to have been passed some time ago.

   5. I strip off Cefn's display code, and use his genetics [to drive my physics code] - Unfortunately, after examining Cefn's codebase for elements which I can reuse I have come to the conclusion that there is nothing obvious there which I would want to use. If asked to take the useful elements from this code, my immediate reaction would be to use none of the elements.

      The codebase does not appear to offer enough to overcome the "somebody else's code" factor.

      It appears to me that the effort required to understand the code, rip out the sections of interest and interface them to my code would be better employed developing my own code - which I already understand and designed to do what I wanted.

   6. The "Blob" codebase is used as a basis for the project [...] - my initial impression is that there's no way the "Blob" codebase can transform itself into anything very useful in the time available.

      It's vaguely possible that the code did do something useful at some stage, and this was removed in order to get reasonable performance under the hacked together space class.

      It's also possible that the code might usefully be developed into something worthwhile. There's certainly a lot of code written that appears to serve "no useful purpose" in producing the current display.

      However, I cannot base decisions on promises and dreams. I have to look at the current situation - which (to my eyes) does not look very promising.

      If I were to contribute to Cefn's code the most obvious place for me to do so would be in revamping the "space" material. This has a clearly defined API, is comprehensible, independent, and I've already written some related code.

      However, I think the space class (and a whole bunch of associate stuff) should be ditched. I can think of no convincing reason why I should work on it.

   There may be other, possibly-viable options. If Cefn believes his code can usefully contribute to the project, then - in my opinion - it should be down to him to make a case for it.

4. Summary

   As things stand, I tentatively recommend option 1 and/or option 2.

   Option 3 may be attractive on "political" grounds - it might be seen as preferable by Cefn to most of the other options I am recommending. If keeping Cefn happy is a priority, then following this option is a possibility.

   Note that a good case will have to me made to me if it is believed that I should be providing much in the way of support for him in this task. I have recently scaled back any plans I might have had in spending much time assisting with this activity. Bluntly, it strikes me as likely to prove to to be a waste of time at this stage.

   Option 4 I am prepared to go along with - but I think it would be really bad for the project.

   Option 5 and option 6 I am prepared to go along with - only under extreme duress. While - in my opinion - option 5 would be bad for the project, option 6 would probably be even worse.

5. Conclusion

   I feel as though I've now spent a fair quantity of time and energy doing things relating to Cefn's work - in preparing an external interface, examining all his code, and reporting on it.

   I have held off writing my own ontogeny and creature-controller code - partly in anticipation of Cefn's contributions. It seems unlikely that I'll be doing that any longer.

   Having seen the current situation, I don't think I should spend any more time on activities relating to Cefn's work - at least until a comprehensible case can be made to me for doing so.