''From a letter to a student studying the work of AlexanderEgyed ...''

I am not familiar with Egyed's thesis. Since reading your email I have browsed online and found that he has published many articles on modeling with Boehm. All of them appear to be of what we call the "big design up front" philosophy, which I reject. I am also not always a fan of "separation of concerns" which I notice is a goal of your work. Here is a thought problem that will illustrate my thinking:

A software manager has 12 things to get done and 12 people to do them. What is he to do?

Most managers would assign each person a thing to do as this seems to achieve the most parallelism. But is this the shortest path to the best code? I think not. I think the manager has essentially told the people to not work together. Perhaps he cannot imagine what they would do together that they cannot do apart. This is most certainly the case as it is very hard for one person to imagine what others will do to solve a problem when they are allowed to bring their own experience to bear.

I favor an approach where the manager gives all 12 people only 3 of the things to do and asks them to work together on them. When these are completed the manager will produce 3 more things to do. The people are allowed to self-organize to complete the work, and they may choose to organize differently each time. This works well because people can learn a great deal about each other very quickly through a "mingling of concerns".  Also, please note that the knowledge learned this way will elude modeling by the manager or any single individual, which leaves model driven approaches at a disadvantage.

My approach also depends on the team's ability to adjust their solution for the first 3 tasks so as to accommodate the needs of the second 3 tasks, and so on until all tasks are complete. We call this refactoring. The big design up front folks believe this is a difficult problem and one to be avoided. It is not. The problem is already simple and made even simpler by powerful refactoring tool such as IntelliJ IDEA.

I fear that the "software engineering" community has taken something that is reasonably simple (programming) and made it very complex. This could be to your advantage as it makes many opportunities for original research. I encourage you to complete your research as planned. Be aware that you are studying an artificial structure that has come into being based on a number of poor choices such as those of the hypothetical manager. You can future proof your work by adding a small section that addresses how it might or might not apply should the practices I promote become widespread.

Good luck and best regards. -- WardCunningham
----

Nice. I'd feel more comfortable seeing some further qualifications, or mention of assumptions. For instance, superficially this seems to assume that the 12 employees are interchangeable to some extent, doesn't it? It wouldn't be unusual for some of the 12 tasks to have requirements that only a few of the 12 employees meet.

I'm hoping that refactoring is well on its way towards taking the entire world by storm, rather than being popular only in certain subcommunities. -- DougMerritt