Alpha Software is focused on enabling developers to create robust, data-driven business applications that run on any PC, Tablet or Smartphone in the fastest, most efficient and cost-effective manner possible.

Share this blog:

Wednesday, July 18, 2007

Perspectives on the CompArch 2007 conference

Beginning July 9, I attended the week-long CompArch 2007 conference at Tufts University. Chaired by Judith Stafford (Tufts University), the conference was organized by some of the leading minds in the field from around the world. This event combined several conferences into one intensive week, including:

The 10th International ACM SIGSOFT Symposium on Component-Based Software Engineering (CBSE 2007)

The Role of Software Architecture for Testing and Analysis (ROSATEA 2007)

The Third Annual International Conference on Quality of Software-Architectures
(QoSA '07)

Industrial Day: An entire day dedicated to the software industry.

And what a week it was! Usually I start to nod off during these long, lecture-filled days. Or worse, a day of rote readings of papers. By 4 p.m., you can often hear the familiar sound of snoring in the back of the hall.

Not at this conference! The entire day was well managed, and everything started and ended on time. The presentations were first-rate, and the discussions were supportive and on-task. This was, bar none, the best conference I have ever attended.

So what was it all about? Researchers presented papers on a variety of topics, all centered on understanding the relationship between software architecture and the characteristics of implemented solutions.

Specific areas discussed included change management, Quality of Service (QoS), runtime verification and monitoring, challenges in architectural dynamics, compositional reasoning, Web services, on-demand service software architectures, architecture-based validation, requirements and software architecture, and architecture-based testing, among others.

The keynote for the CBSE conference was presented by Kurt Wallnau of the Software Engineering Institute (SEI) at Carnegie Mellon in Pittsburgh. He works on the Predictable Assembly from Certifiable Components (PACC ) research project at SEI.

In addition to his fortuitous luck in having an excellent first name (in my humble opinion), he presented a very abstract topic in clear and concise form, and was an active and valuable contributor to discussions throughout the CBSE conference.

The content was interesting, and the technical information useful. But some of the insights revealed by discussions with other participants, and reading between the lines, were even more intriguing. Here are some of my own observations from the perspective of a developer, and influenced by discussions with participants at the conference:

* While the academic community focuses on rigor and completeness, the "real world" of software development is a bit messy. We tend to do the minimum necessary to add value, rather than achieving the goal of perfect software. This is not necessarily good or bad. It's just the way it is.

* In developing an application or tool, one must finish the whole application. In academia, it is possible, and often necessary, to leave an area of a problem unsolved "for further investigation," or to designate it as "not interesting." Imagine leaving off the home page on your Web site because it is not an "interesting problem."

* Despite the difference in short-term objectives, it is interesting that both academia and commercial software developers are working in a constrained, often short-term mode. Developers must ship within the window of opportunity with constrained resources -- including money. Academics and researchers are working from limited grants, often utilizing graduate students who come into a research project, finish their degree, and move on -- rather than staying with a project long enough to develop a true expertise in the problem domain.

* It was extremely clear that researchers really want to be able to validate architectures, including correctness, reliability, and performance, and to move that validation into commercial software development.

* There wasn't much agreement about the feasibility of creating an automated tool to go from requirements to implementation from a theoretical, if not practical, standpoint.

* Research focus is on an absolute, provable solution in a well-defined problem domain. The "real world" can actually handle some degree of messiness, if it adds value to what we have. I'd love an affordable graphical tool that helps me address even 30 to 40 percent of the bottlenecks in my multi-threaded code, without having to profile and debug my way through it.

* More than one researcher commented on the fact that they have solved pieces of the problem. But getting the solution out of the lab and into commercial software is a thorny situation, especially for researchers with limited resources. A large company can fund a project if there is patience and interest. Researchers want and deserve credit, as well as a piece of the profits. In one particular case, the application was built, but the researcher admitted to me that the solution needed an experienced developer to come in and finish it for commercialization.

As a strong believer in the potential value of abstracting and automating the software development process -- hey, that's what we do at Alpha Software -- I was pleasantly surprised by the commitment of the academic and research community to take steps in that direction.

It does seem to me that there are more opportunities for collaboration and long-term thinking. These days, investors don't consider it particularly appealing, but if we can embed the wisdom of experienced software developers in practical tools, we just might save ourselves a lot of the cost in developing and re-targeting business applications that are high in quality, reliability, and excellence of performance.

Maybe. Maybe.


Related Posts Plugin for WordPress, Blogger...