Thoughts from Inside the Box

Computers are now fast and interactive. When writing code, you can just do a compile for every function you write to make sure you got the syntax right. You can write simple test programs to find out how some construct behaves.

Except that this kind of development is extremely bad (yes, I do it too). When you just have the computer tell you if you got the syntax correct, you will not actually learn the language properly. When you use test programs to figure out library use, you don't get to understand the library.

The main problem with this comes when designers of languages and libraries start to expect this kind of development. They become less likely to document their creations properly, relying on users to apply this trial-and-error method. Potentially there will be a few simple examples that do not tell anything useful, just how to use the most basic functionality.

For libraries, having the source available is the worst thing that you could have (I mean, when you're a user of the library). Designers too easily get the mindset that if their user has the source available, there is little need to provide documentation, since the source says how the library behaves. Of course, the source typically never says how the library is intended to behave, so a user can never tell whether some property of the library is accidental or designed.

My belief is that I should be able to write at least a few thousand lines of code only relying on published documentation on the language and any libraries I use, and have this code work correctly on the first compilation, assuming I have taken reasonable care in writing. My current experience is that this seems to be an explicit non-goal for most language and library designers.

# posted by JayK @ 23:45 0 comments

I have been working for four years in a research project in the mobile computing area. From observation during the project and discussions with people I have come to understand some of the things that make for a useful research project. Note that, in full, this probably applies only to the kind of applied computer science that we
do.

First of all, it is important to actually implement something. Developing algorithms and simulating them only takes you to a certain point. Having your code run on actual devices and using real networks is pretty essential to understanding all the various issues.

Of course, it's much easier to just run simulations. There is no need to spend months in essentially boilerplate code, no need to care about limitations and bugs in actual platforms. On the other hand, having something that really works is the only way to demonstrate that your ideas are really implementable and not just abstract nonsense.

Probably the most important thing is to have a common vision. The project needs to know the big picture: what is actually being built. This allows everyone to consider how each individual piece fits into
the whole. In contrast, without the big picture, there is the danger that everyone just does their own thing, making the project more of a collection of people all doing their own thing.

As with all activities involving groups of people, it is essential that the project group can communicate among themselves. When doing research, discussions during the idea stages are necessary to refine the ideas properly.

In general, an informal atmosphere in a research project works best. It is no use to try to communicate during formal meetings or the like. A much better alternative is when people are able to just pop in on each other and start talking. Of course, this means that the whole group should be located in the same place.

You cannot really run a research project in the same manner as you would a software project. Research project workers are pretty much equals, so it is not possible to just impose rules from above. Instead, any structure needs to come from just being sensible, figured out and refined among the group.

Finally, the main enabler for success is the infrastructure. The project needs to be able to share their work and to bring the various pieces together. The hardware and most of the tools to do this should come from the organization's IT department. However, a research project needs to have much more freedom in using their systems than normal workers, so the IT infrastructure needs to recognize this.

To take the most advantage of the infrastructure, it is necessary to have someone (or more than one person) in the group who understands all the collaboration systems that are being used. This person can then design collaboration patterns appropriate to the tools that are being used. But like in all things, this person cannot just go and implement according to his or her whims, but must take into account what the rest of the group feels comfortable with.

I will refrain from evaluating our project according to these
criteria. Suffice it to say that I still enjoy working there.

Labels: collaboration, people, research

# posted by JayK @ 22:38 0 comments