Roadmaps lack detail. Film at 11.

13 January 2010

I love Google Maps on the iPhone. If I find myself with 5 minutes to spare in a place I'm not familiar with, I can start the app, hit the GPS icon, and the screen shows me where I am. If I'm trying to see where I am in respect to other streets and the like, I use the map option. If I'm just wondering what it's like around here I can look at the satellite view to get an idea.

The map is ideal for understanding the layout of the streets and understanding how to get from A to B. There is, however, no detail. It's essentially just a collection of vectors joined end to end and to each other, each vector having some attributes (start and end latitude and longitude being the primary ones, but type of road, speed limit, etc, are others). For detail, you have to switch to satellite view and then you have all the detail you want: houses, trees, open space, rivers, whatever.

Our roadmaps are like the map view. You can see the general direction and the route we're planning to take, but there are little to no details. If you think about it for a little while, you'll understand why. We just haven't had the time to fully flesh out and design everything at the point where we discuss and decide on the roadmap. Instead all we have is a list of features, with some information about each feature, and from that starting point we discuss and make a decision about each. Yep, we could be making a decision based on insufficient or imperfect information, but it doesn't matter. If we waited until we did have sufficient or perfect information, we'd be publishing the roadmap at the end of the year in "satellite" view with flawless hindsight. It would of course be completely useless at that point, apart from as a "this year in review" type blog post.

Of course, there will be errors in the roadmap. Some things won't get done. Some others we didn't mention, will. Others still will be done but in a different order. However the overall arch of the roadmap will be valid. For the 2010 roadmap that means more Silverlight and WPF; it means more work being done to make XAF/XPO the primary choice for business applications; it means polish type work for WinForms, some further investigations into ASP.NET MVC on the web side, and so on.

But what it means for feature X (for numerous values of X) that's mentioned en passant in the roadmap, we don't fully know. We have some ideas, yes, otherwise it wouldn't be there, but how X will be designed and implemented is probably still being decided, and may even require something else to be done first. What it means for feature Y that's not mentioned at all: it's either too small to mention in a coarse-resolution roadmap, or it's probably not going to be done (but who knows).

So, please don't take the roadmap to be any more than it already is. There is no subtext to it. Although I mostly make my living from writing these days, I didn't have the time to add Dan Brown style hints and clues to it: What you see is what you get. It's a map, not a satellite or street view.

(Aside: for customers who don't know the idiom, here's the explanation for "Film at 11".);

8 comment(s)
Michael Proctor [DX-Squad]

well put, if only all customers including mine would take this onboard :)

13 January, 2010
Robert Beaubien


A roadmap is nothing more than what you say.  When supplimented with blogs as the year progresses, and mebby a mid-year refresh, it serves a good purpose.  It is better than the blog only approach DevEx pursued last year by essentially giving an index of where you might be going with the next version and more importantly the version following that.

For example, just by reading the roadmap, I realize that WPF and Silverlight are further behind having a full toolset than I first realized.  This changes my initial thought to start messing with those technologies as soon as VS2010 comes out, to mebby waiting till DX10.2 comes out.  I may look at it earlier, but some of the components I know I will need will not be available till the second release of the year.  I may pick at it a bit earlier, but prolly not for anything serious.

14 January, 2010


It may be useful to consider what motivated your post and deal with core issues which seem to be that there are a number of customers unhappy about direction and lack of understanding in were products such as XAF and XPO are at the present and where you are taking your products in 6/12 months.

Publishing articles about roller coaster rides and road maps with no detail does not send a good message. A map is provided as a guide and should represent the reality, with enough detail to ensure the user is not going down a dead end or falling of a cliff.

This is typically the main reason that projects fail as the stakeholder do not have a clear understanding of the direction. I hope you would agree that the major stakeholder in your products is your customer.

It seems that previous initiatives such XAF steering committee have disappeared without a trace and replaced by articles explaining terminology of the direction rather than the actual directs

Considerable the investment that is made by your customers when deciding to go down the route of using your products, I would suggest that these communications need to be improved and more detailed direction and progress delivered to the client.

For years devex have provided good quality control which do what they say and but I must admit I have become very disillusioned with the changes in the deal with customer expectations.

Take DC in XAF, for example, multiple articles about 12/18 months ago, a good amount of code and then some messages about design issues in XPO and interfaces which can not be resolved without a major rewrite. I appreciate that this is a perfectly good explanation but why the lack of visibility of your own direction that you publish these features and then discover they are not possible without a major change to your products.

14 January, 2010

Julian: The problem many of us as customers have is that the roadmap doesn't provide enough clarity or commitments, because it is by definition, not a firm plan. What you need to remember all the time is that we customers are reponsible for making decisions about present and future projects, and a lot of that depends directly on your components.

For example, we have a project coming up where we need a good quality tree view. At the same time, we're considering using WPF for this project. In my case, it would be very helpful to know specifically when/if you will add a tree view to your WPF collection. Based on this, I can decide to delay my project to wait for you to catch up, to do the project in WinForms, or to look at another component vendor.

These are the types of decisions we have to make on a daily basis. Having a general overview of the direction is really not that helpful from that context. Maybe it helps some customers get a general feeling that "all is well" at DX in general, but beyond that, I don't see the point really.

14 January, 2010
Julian Bucknall (DevExpress)

Andrew: Unlike software projects that produce an application, we do not have a single stakeholder. It's all very well saying the stakeholder is "your customer", but in reality there is no one single customer vision that we can latch onto. It's too simplistic a  notion, but, boy, it would be great if there was. There would be no argument about this feature versus that one, every customer would just agree.

In reality, every customer wants a different set of features, each customer only uses part of our products. So I cannot agree that we have a single stakeholder at all; instead we have a multiplicity of them. Indeed, we also have internal stakeholders that we have to satisfy whenever we make plans for our products. Our roadmaps are the result of some tedious juggling, locked in a conference room for a week.

As for continual communications, I would hope that browsing back through thses blogs over the past couple of years, you would see much increased communications between ourselves and our customers. You talk as if the roadmap is it, and no one ever hears from DevExpress again until the end of the year.

Cheers, Julian

15 January, 2010
Julian Bucknall (DevExpress)

Tom: Your comment brings up what may be the major reason why we should *not* do a roadmap. Despite how we may couch what we say with get-out clauses and the like, customers will take what we say as gospel and then make their own plans based on that assumption. So we may say we'll be doing X, but fail to do it on time, and suddenly we're the bad guys, for some value of bad.

Yes, I can certainly empathize with customers. But, consider this: we also have the same issue with our "suppliers". A minor example: when we decided on the roadmap, VS2010 was going to be released in March and we made plans accordingly. Well, it's now to be released a month later, in April, and we'll have to make a corresponding adjustment. We'll have more time to do more things for v2009.1, but it emphasizes the coarse resolution of the roadmap.

Tree view for WPF? We'll be doing one for sure, but not for release this year. There may be a beta very late this year, but there's too much uncertainty and variability between now and then to promise anything on that score.

Cheers, Julian

15 January, 2010
Aaron Smith

I felt that the road map this year was lighter in content than last years was. However, I still felt it was very valuable to me. It's nice to know the general plan that a vendor has for the upcoming year, and that's exactly what this is, a general outline. I know it's not meant to be the end all be all. This could all change depending on market conditions, and we all know that in this field, things can change very rapidly (i.e. Silverlight).

You cannot satisfy everyone. I for one have appreciated the communications and the feedback from everyone at Developers Express over the last year. Seeing all the new stuff coming out before it's out is nice and also getting inside peak at what's being worked on throughout the year is extra gooey bonus material.

So, even though it felt a little light to me this year, I know that through communication as time goes on, we will know what is going on as it is going on.

15 January, 2010
David Brennan

Interesting analogy. The roadmap seemed moderately good to me, but then I'm only really interested in the VCL portion.

Regarding more specific tasks which are too small to show up, I personally hope VCL ExpressBars V7 is going to finally resolve the inheritance problems with ExpressBars (eg

I guess we will see?

28 January, 2010

Please login or register to post comments.