3 items are tagged with work:

At work, we are currently experimenting with model driven software development. In the past, we were using the UML2 editor on Eclipse to create models of out persistent objects and later generated code directly from the model. The step to create not only Java code, but also other artifacts (like SQL scripts or code to import the persistent data from XML files) was small, the step to create a more abstract level was a little bit larger. Eclipse makes this somewhat simple because it delivers a infrastructure for modeling, transformation and generating code. The most interesting part seems to me the decision, how the higher-level model should look like.

The me, this decision illustrates the problem with MDSD: if forces you to decide for a model. You then need to do everything in this model, and hope it fits to ones needs. If not, you need to create another, higher-level, model, and transform this into the other one. There is no concept of ad-hoc generation of code. But it’s exactly this what makes generating code so useful - the ability to replace every repetition of code by generating it from a higher level description of it.

MDSD only seems to be useful if the higher-level model is used multiple times, because its definition and all the work around model transformation is too much to use it only a single time (or in a single project). But code generation principles are designed to be simple, so it is much more economic to use them. In a recent example, I used grep and a small shell script to create stubs from about 100 XML files (we have a dynamic lookup mechanism in our software, and these files would otherwise been visible to the end user). This is code generation - albeit I executed it only once. With the proper infrastructure in place, I would have written a small program to determine all the files to be used, and would create all the stubs every time during the build process.

So, that’s why I’m currently trying to build a small code-generation infrastructure for Java. It uses bean shell scripts for filling an (internal) model, which is then used by Freemarker templates to create artifacts (one or more). These artifacts could be files, or just another bean shell scripts, which are then feed back into the generation engine, and the process starts over. I would prefer to eliminate the internal model (so I could have bean shell scripts directly creating other scripts), but since Java code cannot be handled as data, this is not really feasible. But even more important is to add the ability for incremental generation (of the final files). Often I need to add some methods to the generated Java classes, and I don’t want to loose them every time.

So, there is still some work to be done, but I hope that it will prove useful (and I think I learned something new from LISP).

Both Turmalix and Mark Levison discuss the problems faced by locally distributed teams. For a current project one half of the team is located in Melbourne, Australia, the other half works in Germany. Out biggest problem - the information flow. If a team sits in a common location, you have many ways of getting information: just go to someone and ask him directly, have regular short meetings, maybe you overhear a nearby conversation, or you meet someone while getting a coffee. All of that is missing now, and the german team sits, literally spoken, in the dark.

The time difference makes things even worse. Currently Melbourne is always 8 hours ahead, after DST this will be 10 hours. We have a windows of several hours only because one team works constantly overtime, and the other people try to start early enough in the morning to allow at least for a daily information sync.

But if there are any unforeseen problems, and somebody needs help from the other team, he normally needs to wait until the next day. This especially requires care when you are checking code into the repository - we had too many cases of non-compiling code, and this can disrupt the work of a whole team for a day.

Our most important tool so far is ICQ, because it allows instant communication like the telephone, but can be ignored if you are busy or something else needs your attention. We try to have regular phone calls (because speaking is faster than typing :), but the heavy schedule doesn’t always allow for that.

Smoothspan writes: To Build Better Software, You Need Fewer People. He talks about the problem that larger teams tend to be slower because of all the communication issues between them. 10 Developers seem to be a reasonable limit for a software team, but I think there are tasks where the limit is even lower. I’m currently working on a team trying to develop a new architecture for a whole software system. We started with about 8 engineers, and it was impossible to even reach a conclusion about the requirements for the new architecture. When the team shrunk to 4 people. with 2 sharing the main work, it was a matter of a few days to get the ideas flowing. We still have the larger team in the backyard, and we will need to defend our result in presentation, but the main work is not restricted to all the goals these people are trying to reach. With 2 people sharing their ideas on a daily basis (while working on different layers of the architecture) we were able to define not only the goals in a nice way, but also to define the architecture in a comprehensive and understandable way - something which a committee will never be able to to (think about all the WS-Deathstar mess). It helps that we are standing on the shoulders of giants, and reading papers from Richard P. Gabriel and Alan Kay was a huge inspiration.

But back to the team size - the limiting factors are communication and the different goals. There is no simple way to have all the ideas of 8 or more people flowing smoothly between all of them, discussing and criticizing them. This is even problematic with 4 people, like in our team. The other limiting factor could be solved by a (maybe benevolent) dictator who just decides what the goals of the project are. But if you want to reach a coherent set of goals in a committee you will need a really long time.

So, for development 10 people may be the upper bound for a working team, but for doing creative work like designing a system architecture, I think 3 is the best size. One person can run into all the wrong directions, and 2 person could be stuck because they cannot resolve their differences. But 3 people can communicate effectively, and should be able to resolve all problems in a short time.