Acropolis: Between Elation and Despair

Microsoft announced “Acropolis” at TechEd 2007. Acropolis is a .NET framework and companion tools for building highly interactive applications.

Acropolis shows promise and I really want to love it but this project appears to be in trouble and seems unlikely to deliver on schedule a year from now.

In this lengthy post I offer my impressions of the Acropolis unveiling and of how others around me perceived it.

In recent years we’ve enjoyed an expanding array of .NET technologies to help us build the parts and pieces of an application but we’ve never had anything like Acropolis to help assemble those pieces into a coherent windows application. This is no prototyping tool. It’s a heavy duty application backbone that can stand up to the complex and shifting requirements of large-scale enterprise applications.

Microsoft Patterns and Practices pioneered the approach with its Composition UI Application Block (CAB) and Smart Client Software Factory (SCSF). All of the CAB components and architectural patterns for loosely coupled, service-oriented, dependency-injected applications have their analogs in Acropolis.

Check out Glenn Block's blog for his views and analysis on Acropolis as it relates to CAB. Glenn is the PnP product manager for the client software stack.

CAB has a well-deserved reputation for inscrutability and a steep learning curve. Most developers shy away from it. CAB seems to be appropriate only for projects with multiple modules, lots of screen, and complex application logic.

Acropolis intends to be far more approachable without sacrificing architectural integrity. We should be able to build simple Acropolis applications quickly and then grow them as the waves of requirements roll in – without having to scrap our initial implementation and re-build the foundation.

This will be a neat trick. Can they do it? I think so. But they are off to a rocky start.

Caveats

Caveat #1: I missed the formal presentations because of my duties as an exhibitor. That means I missed David Hill and Kathy Tam. Bummer. Fortunately, I enjoyed the luxury of a 30 minute one-on-one at the Acropolis stand and a two hour presentation / Q&A for vendors. My comments derive from these sessions.

Caveat #2: I have downloaded the bits and looked at the Acropolis movie but I haven’t installed them yet and I’ve deliberately avoided other blogs as I write this. I’m trying to keep these other influences at bay so I can better reflect how the Acropolis introduction came across.

I fully expect to be wrong on many substantive points. I can fix that later. This post is about “market impressions” – what were the immediate, visceral reactions of an interested attendee trying to navigate among the bewildering array of technologies competing for his attention.

Caveat #3: I have CAB experience which means I am preconditioned to comprehend Acropolis and speak enthusiastically about it.

Netting it out

I’m thrilled to see Acropolis out in the open as an announced “future product”. I see its CAB heritage. I see how it fills in some important gaps in CAB and will be easier to learn and easier to use than CAB. Acropolis could be truly great.

On the other hand, I’m dismayed at the lack of tangible progress on every front. Acropolis is supposed to deliver in about a year. The audience did not believe it. The newly released CTP1 is manifestly fragile. Every API is subject to change. There were no feature commitments. There were no architectural commitments. There was not even an inventory of project goals.

“These are our ‘thinkings’,” they said, “we want to know what the community thinks about it.”

We were told to expect a complete “code reset” in the next few months. One observer called it a “code flush”.

I spoke to several industry veterans. They were almost scornful. Acropolis, in their view, was not even half baked.

I’m much more optimistic myself … but then take heed of Caveat #3: I’m a CAB believer and I really want Acropolis to succeed.

What can be done?

The present situation is troubling but I think it can be redeemed.

First, make a clear list of “Acropolis 1.0” priorities and announce them. The team should feel confident they can deliver on these priorities.

Second, pare down the ambitions. Acropolis has been called “CAB 2.0”. It looks like it wants to be “CAB 5.0”. At this rate it will be “CAB 0.5” and runs the risk of delivering in 2010.

Third, be good to the community. Deliver at least as much functionality as “CAB 1.0”. It’s the programmer’s Hippocratic oath: “do no harm”.

That might mean that the declarative and visual design capabilities of Acropolis don’t ship in the first release. So be it. Acropolis will be ok with the many of us who have been getting along just fine without designers. At least we’ll find out if the architecture and base implementation are sound. Visual designers can enhance the development experience but they can’t replace it. They’re just lipstick on a pig if the Acropolis core is porcine.

SHOULD I USE CAB, ACROPOLIS, OR NOTHING?

This question deserves (and will receive) a separate post.

Everyone agrees – including the Acropolis team – that you should not use Acropolis today. Read about it? Absolutely. “Spike” with it? If you can afford the time. But I personally can’t afford to do more than poke at it with a long stick until it is more thoroughly baked.

“Should I use CAB?”

I say “yes”, for five reasons:

1) CAB is the best architecture available for rich UI applications with more than ten screens.

2) CAB and Acropolis rely on many of the same design patterns and implementation techniques.

These patterns and techniques will be new to you (they were new to me). It’s a significant effort to jump from the way you build applications today to the CAB way.

It reminds me of the leap from procedural to object oriented code. Remember how your first objects were thinly disguised procedures? You got over it and learned to appreciate the benefits of object orientation. I’m betting you wouldn’t go back.

Something similar happens as you learn to program in “CAB style”. I would never go back now.

Fortunately, the knowledge and experience you acquire while building a CAB application will translate to Acropolis. You will pick up Acropolis quickly because you made the difficult mental transition during your CAB development.

This fact was glaringly obvious as I looked around the room. The people with CAB backgrounds “got” Acropolis immediately. Those who didn’t were almost completely lost – I saw a lot of glazed eyeballs.

Yes, Acropolis attempts to shield you from the more jarring constructs. I think it will succeed to a degree. But you will have to understand those constructs at some point and that point could come early.

3) You will be able to migrate your code from CAB to Acropolis when the time is ripe. Not directly; Acropolis won’t mimic CAB and I expect that the class hierarchies and behaviors will be completely different. I understand that Patterns and Practices will work on automated migration tools but I shouldn’t have to count on them

Designing in CAB style means factoring your application in a way that will move readily to Acropolis. Imagine the difference between migrating a traditional, green-screen Cobol program to .NET and migrating a Java program to .NET. Neither is automatic. But the structure of the Java program might come across almost intact.

4) There is no better alternative. You could roll your own infrastructure. I’ve done that several times already. Homebrew has one advantage: I (think) I understand what I wrote. Everything else is a negative: I’m working on plumbing instead of product, I’m the only one who understands it, I have to maintain it, it breaks down under the stress of new requirements, I can’t share code or concepts with anyone else, I get sick of it but can’t move on, … and so on.

Oh … did I mention that I’ll be stuck with an application infrastructure that is difficult or impossible to migrate to Acropolis when its ready?

Not an issue? You mean you won’t be able to afford to migrate for years to come? Well CAB is not going anywhere. It’s open source and bound to be better documented than anything you write yourself. Your application will be in better shape with CAB than with your own infrastructure whether you migrate to Acropolis or not.

5) Acropolis may not arrive for quite some time. I don’t want to jinx it. It just looks to me to be far more than a year off the pace. It might ship on time if they trim their ambitions. I can’t bank on it.

That means your CAB application will have a longer life than you expected.

THE GOOD

In this all-too-brief section I report the encouraging signs from the TechEd show.

The Presenter Was Great

I’m going to be dishing some tough love in this post. I want to be sure that we don’t shoot the messenger (and I don’t mean me). The fellow who demonstrated Acropolis knew the product, knew what he was doing, knew the “why” of every step, and clearly loved Acropolis. He was also honest and forthcoming which I sincerely appreciated. Should he have told us that today’s bits were likely to be completely different in CTP2? If that was speaking out school, I can only thank him. Imagine how pissed we’d be if they sprung that switcheroo on us later.

Acropolis Is Real

The demonstrated code worked. The short examples conveyed the key points clearly. He jacked the code around at will, freely straying from the script, and there were no unpleasant surprises.

Ok, that isn’t a particularly high hurdle to clear but at least it wasn’t “slideware”. The Acropolis designer is clumsy – I would almost say it is weird. But it never failed (a tribute to the presenter’s expertise) and showed real promise as a dynamic, visual representation of the application’s components (of what we CAB folks know as the WorkItem).

I hasten to add that he played it extremely safe. He dragged components on to the Acropolis design surface but never removed them; removal and most other alterations were made through direct edits of the Acropolis XAML. This may be forgiven to a degree - we all know that designers are the last and least stable elements of a product – but there was more timidity than I’d like to see when we are presumably only a year from release. We were also given to understand that the ultimate designer would be dramatically different.

The core components seem to be in place. I thought I could identify new versions of my old CAB friends: WorkItem, WorkItemController, service, view, presenter, command, and event.

Navigation and ConnectionPoints

The most obvious Acropolis improvement over CAB is its attention to navigation. The UIExtensionSite is the weakest of the important CAB elements in my view. Acropolis appears to have given this more careful thought with its attention to “Navigators”. I don’t know what they are yet but I can tell I’m going to like them better than UIExtensionSites.

The “ConnectionPoint” unifies properties, commands and events although precisely how escapes me at this time. I was satisfied to see that it gives us a better, easier handle on communications between view and presenter and between presenter and application controller without sacrificing the loose coupling essential to these design patterns. This is one of the most difficult tricks in CAB development so, if they’ve nailed it, that is a significant accomplishment.

Templates and Inheritance

Acropolis seems to have distanced itself from the software factory approach. They have turned to Visual Studio templates instead.

I really like the software factory in concept so this seems a step backward at first. But I think it’s the right call for now.

SCSF ships with a collection of software factory recipes – and I can’t use any of them. That fact never troubled me. I assumed that the given recipes were for demonstration only. The View/Presenter recipe, for example, generates a view that inherits from UserControl, a presenter that inherits from SCSF’s Presenter class, and a “do nothing” interface.

A serious CAB application would use views and presenters that inherited from application-specific base classes. The interface is often unnecessary and, if truly needed, should probably inherit from a base interface. I have to be able to write my own recipes.

Unfortunately, recipe development and deployment is a difficult, time consuming task today. I too have turned to Visual Studio templates which work fine for now.

The Acropolis team is right to focus on the core elements of their platform and leave factories for another day. The Patterns and Practices team could explore and improve Acropolis factory support on its own without impeding Acropolis development. Just making factory development easier would be a hugh accomplishment.

Acropolis intends to ship with a healthy set of starter templates that inherit from base classes. That is a good step but template creation will be as much a requirement of Acropolis development as it is of CAB development. The Acropolis team should provide guidance in this area.

The Visual Studio template macro language seems pretty lame. Maybe I just don’t know how to use it. In any case, the Acropolis demonstration leaned on wizards to extend their templates which should tell you something.

I don’t think wizard writing is going to be easy for anyone outside the Visual Studio team. There was mention of providing Wizard extension points; that is an initiative that gets an enthusiastic vote from me.

THE BAD

Earlier I summarized some reasons for serious concern. I take them up in detail in this section.

Why Acropolis?

The Acropolis team has done a poor job of articulating why Acropolis exists. It has the look of a solution looking for a problem.

The demonstrations I attended didn’t even attempt to explicate the problem that Acropolis addresses.

I know I promised not to look at blogs or documentation – but I peeked any way. There is almost nothing on the “why”. Instead we are taken directly to the “how” and even this story is relentlessly obtuse as in the following representative quote:

“it really boils down to providing a framework that allows you to build modules that encapsulate different client application strategies, providers or patterns, that you can then combine in various combinations to ‘compose', or assemble, an application.”

I can’t sell this to management. I can’t sell it to developers. I’m going to have a hard time getting any kind of adoption.

Moreover, if we can’t explain the value proposition clearly, we are sure to lose our way in setting goals and priorities.

Do I have a “statement of purpose”? Sort of. It starts like this:

“.NET gives us a lot of technology for building the parts of an application. We have some technology for connecting those parts behind the scenes where there are no humans to bear witness.

But we sorely lack technology and guidance for building entire people-oriented applications with their rats nest of screens, navigation, business rules, etc. We’ve had to cobble together this infrastructure for ourselves. We’ve done it over and over and over again. We’ve each spent an enormous percentage of our time on this kind of plumbing, we do a lousy job, and we can rarely reuse our efforts on the next project. As the application grows and requirements change, our infrastructure becomes more frail and less accommodating. A lot of the really bad bugs live down here.

Acropolis provides the application infrastructure we need to build robust applications with rich UIs, applications that can respond well to the addition of new modules, to integration of existing modules, and to sudden changes in application logic.

You’ll want to use Acropolis for applications with just a few screens because it takes only a few hours to get them up and running with a production-ready look-and-feel. But it is not a prototyping tool. Idling under the hood are components and architecture to propel a modularized, distributed application with hundreds of screens and thousands of business rules.”

Sure it sounds like a marketing pitch. But at least I know what the problem is, what Acropolis intends to do about it, to which situations it applies, and how hard it will be for me to get started. It even implies some metrics for success.

No Goals, No Priorities, No White Paper, No Commitments

Maybe they exist but they were not available at the show and I’ll be damned if I can find them online. There don’t even seem to be PowerPoints!

The presenter would say “we’re thinking about doing this” or “we’re thinking about doing that”.

That's nice but what is Acropolis going to do for sure. I asked if there were any announced design goals. “Nope”. Priorities for the first release? “Nope”. Architectural commitments? “Nope”.

How can this be?

I remember well how LINQ hit the scene one year ago. The purpose and goals for LINQ were absolutely clear. There were early bits and we knew things would change. But we there were excellent, detailed white papers and we knew that LINQ syntax was stable. I’m sure it has changed some in the last year but not much.

Contrast that with the Acropolis announcement. No white paper, no goals, no commitments.

Here is the official line on the present state of Acropolis.

“We're fairly early in the development cycle for Acropolis. We decided to
release this CTP release so that we can get your early feedback on the direction and features of Acropolis and to allow you to get involved in its evolution.”

That does not sound like a Microsoft product arriving any time soon. Anders wanted our feedback too. But it wasn’t an open slate. “Hey, Anders – how about moving the Select to the front where it is in SQL?”. I don’t have to ask ‘cause it ain’t going to happen. For good reasons laid out in meticulous detail before I can think to ask the question.

The Acropolis position is practically an invitation for design by committee. Hey David, give us some boundaries, ok?

No Silverlight Story?

As I said, one of the really curious aspects of this announcement was the perpetual refrain “we’re thinking about …”.

In the absence of announced priorities, it is incredibly difficult to plan for Acropolis. Moreover, the few hints of the undisclosed priorities suggest a faulty process. Permit me two examples.

One of the things the Acropolis team is thinking about – seriously I suspect, given that it came up repeatedly – is enabling Acropolis applications that span AppDomains.

Sounds cool, I guess. I remember that the CAB community was polled about this feature several months ago. It didn’t get many votes as I recall.

No wonder. It’s hard to think of an enterprise application that really needs this feature. I can think of only two scenarios in which the ability to load in an AppDomain might be useful.

1) To isolate a new module that might be unstable; if it failed, it couldn’t bring the rest of the app down.

2) To enable de-installation of a module at runtime without terminating the application.

I know these are important scenarios for Visual Studio. I just can’t think of an enterprise application I’ve seen or worked on in the last thirty years that needed either of them. Maybe I’m missing something.

Now contrast this dubious initiative with another capability: running in Silverlight.

I asked if Silverlight support was on the board. I was told it had been discussed but did not have momentum in the team.

How can that be? Silverlight has to be one of the most important technologies around and it bears directly upon the breadth of the opportunity for Acropolis applications.

Acropolis is a technology for building smart client applications. The rap against smart clients is (a) you have to install them and (b) they leave a footprint on the client.

That means we can’t write smart client applications for corporations that lock down their PCs and we can’t write smart client applications for consumers; neither market will tolerate any apparent installation or client footprint.

Silverlight gives us a shot at delivering the smart client experience in a safe browser sandbox which should be unobjectionable to security-conscious businesses and worm-wary consumers.

Maybe it’s just too hard to do in release one. I’m cool with that. But give the feature some love. Don’t talk to me about cross AppDomain applications (which won’t be in release one either); tease me with the future of Acropolis in Silverlight.

Immature Code

It was abundantly obvious that the CTP1 code is no where close to the code that will ship. We were told straight up that we should expect the next few CTPs to be “code resets”.

I appreciate the honesty. It's critical that I know that now rather than discover it later. But knowing it doesn’t help me warm to the prospect of investing serious time with Acropolis now.

It’s great that you want to “allow [me] to get involved in its evolution” but how can I offer help when everything is up for grabs?

Here’s a news flash: I don’t want to design Acropolis, I want to use it.

Unit Testing and Debugging

The Patterns and Practices team have been strong proponents of unit testing. All code is shipped with unit tests. The Model – View – Presenter (MVP) pattern is largely justified on the grounds that it facilitates testing.

Visual designers are wonderful for rapid development but they rarely deliver testable, reusable code. Acropolis is as big on designer-based development as it is on design patterns like MVP. There wasn’t a word about unit testing. I asked about it and was told that the Acropolis team has examples. That’s great but it doesn’t seem to be a consideration intrinsic to the designers. For example, I don’t see evidence that the designers emit a test harness.

Debugging CAB is notoriously difficult. It is not strictly the fault of CAB; both static code analysis and debugging are a challenge for any infrastructure that relies upon significant amounts of indirection.

Intrinsic tracing support and CAB visualizers are two tools that improve our ability to figure out what is going on. What is Acropolis doing about this?

Where Have You Been For A Year?

Acropolis has been in stealth mode since its inception. The last CAB release was December 2005. It’s been frozen solid since then and a number of our customers who bet heavily on CAB have been openly worrying that Microsoft will drop CAB altogether. Anyone not under NDA was kept in the dark.

The long silence seems ill advised. You weren’t interested in my input for the last year and suddenly you want to “allow [me] to get involved in its evolution”! That’s vaguely insulting, don’t you think?

Anyway, the word is out now. Acropolis is “CAB 2.0”. Sweet.

So what have you been doing for the last year and a half? CAB gave you a running start at Acropolis. Where is the CAB inside Acropolis? I think it's in there somewhere - I can hear it rustling around under the covers – but it would be nice to have a clear idea about how the highly successful CAB patterns and practices found expression in Acropolis.

No Reference Apps

None were shown. There were roughly six single screen demos – all very cool - but nothing demonstrating the concerns of building a composite application. There wasn’t anything on the (tiny) scale of the CAB “Bank Teller”. Did the Acropolis team reproduce “Bank Teller” as an Acropolis app?

I realize that teaching tools are not first on the agenda during early stage development. But reference applications are not just educational. They are a proving ground for the product. It is hard to have confidence in Acropolis as a foundation for large, complex, composite applications when there is not a single example of even a simple composite application.

I am hoping that I am wrong and that I’ll find such an application when I unfold the CTP1. Remember that I am reporting impressions from the show. There was not even the hint of a reference app at the show. If it were my product, you can be sure I’d be demo’ing the biggest app in my bag.

What’s up with the documentation?

I’ve already harped on the lack of white papers. I’ve peeked at the help file. It’s really lame; a mere 13 printed pages if you don’t count the reference help generated from XML and the two “walk-throughs”.

I thought the Acropolis team might have learned an important lesson from the CAB project: documentation is critical to product success. CAB adoption has struggled not because it is hard but because it is largely a mystery.

Well there is about 10 times the documentation for CAB as there is for this CTP. The Acropolis team should have booked a tech writer from the start and turned her loose on adapting the CAB documentation to Acropolis. The CAB forums are full of valuable material. I’m not referring to the answers, which likely apply only to CAB. I’m talking about the questions, which will be just as relevant to Acropolis as they were to CAB.

Can any one at Microsoft produce a decent video?

The lone video on the Acropolis website has a great script but it is blurry from the start and seems to get more so the longer it plays. By the end we're looking at the application through a thick gob of Vaseline.

I’m playing it now in Windows Media Player. I can see it was produced with Camtasia. I make Camtasia videos all the time. I deliver them in (horrors) Flash because Flash videos play clearly on all media players and in all browsers.

I’m all for eating the Microsoft dog food but there comes a time when you have to concede that the message is more important than the medium.

Conclusion

Acropolis has a great pedigree in CAB. The CTP1 first look is suggestive of an exciting future. But if the project continues on its present course, that future is years away. Someone had better trim the sails and head for port soon. Until then, this ship is lost at sea.