« Mik Kersten : Comparing AOP tools | Main | Ron Bodkin on Aspects and Security (AOSD 2005) »

March 18, 2005

Dave Thomas' keynote at AOSD 2005

Dave Thomas' keynote

Transitioning AOSD from Research Park to Main Street

Dave was the founder and CEO of OTI (not Pragmatic Dave). Currently CEO of Bederra Research Labs.

One of the most important things you can do is fail fast and fail often. Nervous of the black and white world in which technology is painted. We need dialogue, not just propaganda - we should listen to each other and to critics.

complexity of application development today

We live in a very complex world. There is latent technical complexity, accidental complexity. Open source from the OS to the application allows every customer application to be "unique". This creats an immense tool and services opportunity to make an even bigger layer cake :). (Dave is a big fan of Spring btw).

Latent complexity... so many things you have to know in order to be able to do something (objects, components, interfaces, patterns, AOP, MOF, UML, Java/C#, XML, Web Services, Scripting, Messaging, ...

New acronym: TMS (too much stuff) its PMS but for engineers ;)

There is gratuitous technical complexity for simple problems. See e.g. http://www.jot.fm/issues/issue_2003_09/column1 All a customer wants to do is query a database and get some results... but they have to deal with objects, persistence frameworks, ... and so on.

Accidental complexity is the real killer. Fragile, complicated, redundant: multiple technologies with 100s of APIs. Requires extensive expert level experience with platform technologies. Normal person just trying to do things cannot keep up. We have complex and bug ridden libraries: The Deplorable State of Class Libraries

We have a skills gap. Java programmers can be had really cheap - every college produces them and Sun certifies them (so they must be good, right?). But the skill level has been dramatically lowered over time. They don't understand comp sci or basic engineering. (So how will they understand aspects?). Once met someone with a masters in SW Eng. who had never written any code!!

challenges of application development 2010

Need to be business driven versus being technology driven. Based on sound and deep understanding of the business. Complexity mandates inter-disciplinary collaborative definition and development driven by business experts. First time applications vs traditional process improvement. The ultimate pair programming is a programmer plus a business expert. We need support for high performance teams. In 2010 there will be a bunch of legacy platforms (J2EE, .NET, ...).

Dave is not a fan of MDD. We need development in real-time, execution in real-time, massive amounts of data, ... Are our languages and tools up to it?

Experiences of selling new technology

Sell concept and benefits relating to previous/current practice - avoid the language/tool debate. Illustrate with an example which makes sense to them. (Nice anecdote, selling Smalltalk to execs "can't we name it something better - maybe Bigtalk??"). Address the critics concerns before they ask. Explain that tools help productivity and quality. Aside... what if the guys who did J2EE had looked at something like CICS - which already had separation of concerns and the developers only had to write a small piece of business logic. Tuxedo and MTS were the next generation of ideas built on CICS.

Every talk they (OTI) gave started and concluded with this message "this is exactly the same as you have been doing all along, except that it is completely different!". Respect what people are doing and explain that you understand their problems. You have to understand the languages of the people that you are talking too. Technical cultures (eg. SAP) are much more diverse than human cultures!

Early adopters pull the ideas and tools and move aggressively ahead. Will inflate your most conservative claims. Will alienate others inside their company. Position yourself between the early adopter and those who fear/oppose them. Keep the advocate with you, but make sure that you talk to the real customer too.

The later adopters have a long list of questions they just need to have answered. Often have very different skills and much less software engineering experience than any AOSD attendee can imagine. Want standards, customer references, case studies and insurance of major vendors/ISVs. Make sure you always operate with honesty, integrity, and modest claims. Dave : we actualy persuaded ourselves that people could program in Smalltalk - they can't! Gurus can, but the man on the street can't.

AOSD Works!

Encourage separation of concerns as a best practice. Encourage role/subject modelling. Refactor to improve maintainability of large complex products, eg. middleware. Refactor to improve usability of large compelx products, eg. middleware. Manage variability of product line assembly/deployment. (Dave really is not a UML fan at all...).

J2EE desparately needs an industry standard aspect library to provide a simpler programming model. Java desparately needs a better model than J2EE.

AOSD Analysis and Design

Revive an understanding of role modelling and interfaces. Provide an implementation of use case extensions. Requires a revision to UML and associated tool chain. What does A/D mean in the presence of aspect libraries?? What does it mean with respect to architecture? It was shown yesterday that aspects can encode architectural constraints - we need to get that message out more (AMC - this is a ref. to the talk that Gregor and I gave yesterday).

AOSD Software Engineering

Who, where, when should AOP be applied? What does unit testing, acceptance, regression testing mean in the context of aspects? How can we avoid the problems we found with before, after, doesNotUnderstand etc. in large Lisp and Smalltalk programs? How does one debug at the level of the abstract? Dave is now talking about how positive the dialog at the "Adopting AOP" talk was yesterday - it took the OO community a long time to get to that stage. Can powerful tools really fix a bad platform - maybe we need to build a good platform with AOP rather than fix J2EE?

AOSD Speculation

When do we need an aspect language versus an aspect transformer vs an aspect runtime? Is there a useful subset of AOSD that can be implemented via existing OO mechanisms? (Eg Envy/Developer, AspectJ2EE). Are there standards of practice and convergence of key concepts? Are some problems better solved using non-OO languages/techniques - eg. dependencies. These are all interesting questions for us to consider. Teaching people just UML and Java is just not enough.

We need to teach things like computational reflection back into CS programs. Read SICP, The Art of the MetaObject Protocol. People who have read and studied these books (and ones like them) are always the leaders of new ideas. Functional programming -> design patterns. Meta Object Protocols are the big ideas behind AOP/SEP. Separation of Concerns. Could microsoft pheonix be the eclipse for code generation?

Some predictions... with the usual caveats. AOSD will at a minimum be a master craftsman tool for systems programmers. It isn't clear that AOP will be "outside" for application developers? AOP will likely find success in sw product engineering vs application dev - in the same way that OO CBSE has. Aspect libraries should increase the use, and also reduce the need for aspect developers in fawour of aspect users. AOP Analysis and Design will find a slow adoption, and may get stuck behind UML 2. Teaching AOSD concepts - separation of concerns, role modelling, and meta object protocols may find a resurgence. AOP will be a challenge to position in undergrad curriculum.

Language neutral tools will find better acceptances than new languages. @lt;yuck @wins /yuck> AOP in every language is easy but not interesting - eg. aspect javascript. AOSD tools will fill current gaps eg. true OO->AOP refactoring. AOP load/deployment time weaving will become the preferred implementation. AOP OS and VMs will remain a research topic for at least another generation of commercial VMs. Hopefully by 2010...

AOSD Research

What formal machinery can be usefully brought to bare on AOP? Does the holy grail of a declarative reflective language philosophized by Brian Smith really exisst? AOSD suggests we may be closer to true meta programming? program composition of fragments of requiremens, design, code into programs eg. hyperspaces, feature oriented programming, beta. How many people have a basic understanding of monads? (only 1 or 2 hands). "This is a problem folks" - you need to go look at what they are doing. Do classes really matter??? We have a simple abstraction... but maybe it's wrong. The model given to you in physics 101, but the simple abstraction is wrong. To do more powerful stuff in physics you need to understand the deeper stuff. Keep AOSD as the name of the conference, and encourage and welcome a broader community to come. The great tool that Dave wants is one that easily allows you to take a large program and discover and refactor into aspects. Will be done by teams of specialists initially. Please do not chain graduate students to eclipse, java, c#, solely to claim that your research results have industrial relevance. Get the ideas out, and then you can go through the industrial phase. Buffer the industrial noise - find ways to do simple quick demos.

Q & A

Q. What about the relationships between people and programming languages? Different people work in different styles. A. Dave is a big fan of DSLs. E.g. functional programmers tend to have strong mathematical backgrounds. However, we shouldn't be ignorant of the benefits of the thought processes and ideas in different programming language cultures. Would like to see a cross-language family culture.

Q. We can study what's working in large systems and generalize. We can also research at a very small scale according to principles and then hypothesize that they scale up. Which is better? Any advice? A. Success of many people attributed to "split brains" :- enjoy the elegance of a good theorem and a clean solution, but also like seeing them worked out in "scruffy" systems. Eric Myer at Microsoft has had a big impact on Dave Thomas' thinking recently. Don't look at the code... look at the people who build it. SW is a craft, design is a craft. Schools of architecture and design don't have "go to class...", they have lots of studio time etc.

Q. I liked the cut the BS aspect of your talk. The reality of our life is that we have to get money to pay the bills. How do we reconcile the economic constraints with the message to go after great science? A. Solve the problem that the customer wants solved with the technology they want it solved in, but do it using tools you built using whatever technology is the most appropriate. E.g IBM process that said you had to have a complete functional spec before you could do a prototype. So they built the prototype and from that created the spec! This was a much better strategy than fighting the process. They had tools that created what was needed. Find ways to play within the needs and culture of the customer, it's not hard...

Q. What is Dave's vision of the sw industry once all the bad technologies have been simplified? A. There is a whole other parallel universe for application development - very many people who are not really bothered about J2EE etc.. J2EE will only be relevant as a legacy technology in 15 years. The world will move to those people who understand the application domain. Innovation happens at the edge.

Posted by adrian at March 18, 2005 11:52 PM [permalink]

Comments

Post a comment