Roadmaps and promises

20 May 2011

I’ve just replied to a thread in our General Discussion forum that I think is worthwhile bringing to a wider audience here. The backstory is that a customer is pointing out that a particular feature promised in the roadmap didn’t make it into DXperience v2011.1 and this omission has compromised his plans for the release of his software application in the summer. Whereas I am totally sympathetic to his predicament – “WTF am I going to do now?” is what I’d be saying for sure – there’s part of me that is less so. Let me repost my reply:

sand stone tabletphoto © 2008 Howie Le | more info (via: Wylio)Every time I write a roadmap, I insert language to say that although we hope to complete everything we describe in it, in reality some things won't get done, others will get done early or late, and yet others, previously undefined, will suddenly get done instead. Every time we publish a roadmap, someone gets upset that feature X (for some value of X) didn't make the mix during the year, and so every time I resolve that the next roadmap I write will contain stronger language pointing out the caveats. Here's the paragraph from the 2011 roadmap:

And what are those caveats? As is usual I have to sound my standard note of caution. These plans are our best estimate at this point in time for what we should be able to do in 2011, given our resources and our understanding of the technology landscape in which we operate. Any dates given are estimates. Any functionality we describe in this roadmap, especially the further out it is, may be postponed or cancelled altogether. We strongly advise our customers not to make firm plans based on what they see here: in an industry such as ours, things can change very quickly and we have to react just as rapidly to new opportunities that may present themselves.

Although I am sorry that the lack of X in our v2011.1 release has thrown off your plans, I honestly don't know how to make this language any clearer. The roadmap is a guide only. It's a way of communicating what we envision doing over a period of 12 months, not a set of features on engraved stone tablets from which we won't deviate.

I firmly believe that a roadmap -- despite these caveats -- is a worthwhile document to produce for our customers. It gives them a idea of what to expect and reassurance that, heck, DevExpress is planning and executing on some great new features. It's also beneficial for us: it lays down a development path for our programming teams (so they don't go off on wild "wouldn't it be cool" tangents), and it gives strong goals for our marketing teams (booking ad space in magazines requires 3 months or so, for example), and evangelists. The alternative -- no roadmap at all -- is unacceptable to me.

We’re all developers, right? We know that drawing up set-in-stone software development plans for a full twelvemonth is silly: there will always be events and circumstances beyond our control that will alter those “best laid plans”. However, having the guidance of those plans, although they should be treated as being more nebulous, is still valuable. I mean what I say: I believe spending the time discussing and writing a roadmap is more constructive for you, our customers, and for us than the alternative, staying quiet until we do the sneak peeks.

We just have to be careful in how we interpret a roadmap. It’s a guide, not a set of promises.

What do you think? Do you like the roadmap? More provocatively: Do you produce a yearly roadmap for your customers? Do you stick to it no matter what? Or are you more “event-driven”?

32 comment(s)
Neal

I guess you're not running for President? :)  "My lips are flappin"

20 May, 2011
Julian Bucknall (DevExpress)

Neal: Like "Ahnold", I'm not native born. No presidency for me ;) No maid either, but that's a different story.

Cheers, Julian

20 May, 2011
Jose Rolando Guay Paz

Julian, while I completely agree with you that a roadmap is basically a guide and not a promise, I'm a strong believer that open communication should have taken place.

For example, if functionality x,y,z was in the roadmap to be delivered in Q2 2011 but somehow in late May you know that "y" is not going to happen, just make an annoucement and say it. It will be easier for all of us to digest something early in the process that later when the product is already cooked.

What do you think?

20 May, 2011
Martin Pelletier

Hello Julian,

By the time we get 2011.1, will we have the 2011.2 before the end of year?

I love getting my DevExpress update gift before Christmass.

I know, bad joke. Long week for me ;)

20 May, 2011
John E. Young

I like the roadmap you provide. Keep in mind what some of us use it for though. I have to provide a list of purchases I need for the new budget year. If I want something, I have to explain why and sometimes, there are items on the roadmap that make a DX license renewal an easy sell. I cannot buy anything, even license renewals unless there is something to be gained from it. Just updated releases is not good enough unfortunately.  So if you say X is coming, I use that for a reason for a license renewal, and if X does not come, it makes it much harder the following year to request it again.  Also, if it is not in the budget, it does not get purchased, so taking a wait and see approach does not work.

That is my life.  Not having X done is not an issue for me, it just makes life a little harder if I happened to use that one for a purchase justification.

20 May, 2011
Matt Jacobi

The roadmaps are great. I always look forward to them. I also fully understand that things can change -- as a developer, how can you NOT understand that? Keep up the good work.

20 May, 2011
Glen Germaine

Julian, you could go around to every customer and tattoo it on every forehead and you can bet someone will complain that they don't have a mirror, therefore they didn't get the message.

You're damned if you do release a roadmap and damned if you don't.

I too was after some functionality that hasn't made it, but your language has always been perfectly clear, therefore, whilst disappointed, I'm not going to be turning up on your doorstep with the Feds.

20 May, 2011
Liu Xinrong

I make a DX license renewal because I needs the newly features on the roadmap, but this too many new features not implemented, and against  a renewal of the original intention

20 May, 2011
James Zhong

I also purchased DX Universal subscription, and I'm satisfied with what I get from the license and the great support.

Why I will renew the subscription is just because DevExpress constantly and continuously improves the products by adding new features and fixing issues quickly, even some features X and Y listed in the roadmap are not implemented because of their limited resources. After all, without the subscription, my product release date will be postponed for months.

:)

20 May, 2011
Andre Labaki

Hi Julian,

First I must say that I have always had a big admiration to the whole devexpress team for the wonderful products and support they have offered me over the years.

And regarding your post, I agree with you that you made it very clear that a roadmap is not a commitment and we should not make plans based on it; however, the way you handled the "disgruntled" customers was, in my opinion, insensitive if not offensive.

If I am ever asked by one of my customers why I did not deliver a feature that I said "I will try to deliver sometime in the first half of the year" and I answered "WTF am I going to do now" or "Although I am sorry that the lack of X in our v2011.1 release has thrown off your plans, I honestly don't know how to make this language any clearer", let alone making that comment public, I will immediately be kicked out and loose this customer forever!

In my opinion, a simple apology and a "brief" explanation as to why you were not able to deliver this feature (resources, unexpected issues, etc.) would have sufficed.

Yes, we are all developers and sometimes (of not often) our 12 months plan get sidetracked, we all know that. But the key is managing expectations and open communication! I am sure that the decision to not deliver feature X or feature Y in 2011.1 was not taken one day before the launch, therefore if you let your customers know whenever you drop a certain feature from the roadmap, I am sure that you would face much less heat and allow us to manage our customer's expectations as well.

In this day-and-age competition in the software industry is extremely high and I am sure that everyone of us is trying to maintain an edge against the competition in any way possible. Basing our roadmap on our partner's roadmap is risky but sometimes necessary. So in my opinion, if devexpress thinks of its customers as partners, then an open communication is extremely important! Simply let us know when you decide to drop or postpone the delivery of a certain feature as soon as you know it and I am sure you will gain the loyalty of most of us. I am not saying that there will not be any disappointments but at least we will have more time to plan and adjust.

Again, I will stress that I admire the work that you and the whole devexpress team are doing and the excellent products and services you are delivering, I am simply suggesting more transparency.

Thanks.

21 May, 2011
Severin Meyer

As soon as a feature has been announced officialy, all changes to the delivery of this feature has to publish immediately.

The problem for me is now, how can I count on DevExpress promises.

In the support center there are so many issues with "Accepted - Release TBD" which are open for years, so this is more than a farce.

Then you have published a roadmap. But now there many missing features. So what will happen to the 2011.2 roadmap?

A previous question to the support leaded into the answer: "There will be a Theme Editor in 2011.1, so please wait".

After installing and spending a lot of time on the beta release of 2011.1, it ended up to a new question to the support: Sorry, but we haven't done it by now.

You should publish a more lively roadmap.

At the beginning just describe your plans for the next 12 month.

As soon as you know, that a feature will be done in a specific release, publish this in the roadmap.

If a feature is late and will not going to be published in a previously announced release, publish this also in the roadmap.

So all impacts on the roadmap should be updated month by month or day by day, so we have always a roadmap for the next 12 month.

21 May, 2011
John Botibol

Hi Julian

The Roadmap is essential, it keeps us informed of plans. However (as always :-) ) it is a big disappointment when something is not delivered. I guess psychologically having read it it becomes "expected". Here's an idea, not sure how feasible it is but we are using something similar with our customers (who are not so forgiving regarding delivery dates).

In the Roadmap how about some sort of prioritisation. This could be used by the development team to re-focus resources when neccessary so that the chances of key features being delivered is greater.

I am assuming that the XPO security feature is the matter being discussed, if so then I guess it's a massive undertaking and perhaps with priorities then maybe Workflow could have been rescheduled. (What, XAF, me?)

Best wishes

John

21 May, 2011
Jasen Fici

I am more inclined to think that *published* roadmaps should be more reliable, ESPECIALLY as a tools developer.  

Leaving bells and whistles out of end user applications is a little more forgiving, however, application developers look at your roadmap and need to use it to determine their own roadmaps, so yours is a bit more important.

If they can't rely on seeing what they read, then I think that causes more problems than it solves.  I do not think it does any good (and in fact, causes more problems) publishing your plans if they are that volatile.  Your words of warning at the beginning of a roadmap simply means "hey, everything I am about to read is completely useless to me, I can't really schedule or wait on any of it because its not really a release schedule, its just DevEx talking about what they would *like* to do".

I love you guys, been using your tools forever, but if I read something that talks about your upcoming releases, I would like to know that what I am reading is reliable..

21 May, 2011
Damien Bhanji

Hi Julian,

Roadmaps are essential. At the very least they prompt customer feeback, both good and bad, which lets you know if you're on the right road or not.

I fiind the DevExpress roadmap very useful but never count on it in order to deliver functionality to our customers. There is always more than one way to provide a solution, even if it requires other vendors controls. As mentioned in another post we use someone elses HTML to PDF converter, but with this latest release we may finally be able to get rid of it and use the export facilities in the HTMLEditor control. But we planned round that several years ago.

Reading some of the comments I guess the one change that may help is if a major feature gets dropped then to publicise it, you can't get fairer than that.

Compared to the likes of Infragistics and ComponentArt you are still streets ahead despite the odd wrong turn on the roadmap,

Damien Bhanji

Take A Byte Limited, UK.

21 May, 2011
Drazen Dodig

If I promised my customers certain feature and then, while not being to deliver on the promise, I explain it in the way Julian did, I would not have that customer anymore.

It is as simple as that.

Learn some humility and how to apologize.

Real reason why you publish "forward thinking" roadmaps is to get more sales. By promising an feature, you are telling your customers: trust in us and buy/extend our product.

What do you think happens when you betray that trust?

I know for sure that if we knew what we know now, we would have never switched from TMS controls. Instead, we now have to upgrade for subscription TMS, pay 3x more, just because we simply do not have time to implement the alternatives anymore.

21 May, 2011
Juergen Vogel

Hi Julian,

I was one of your users who asked for a functionality which was on the roadmap and now not in beta. I fully understand - as many of us already mentioned - that things promised may not be done because of certain circumstances.

And if you'll commit this at the point you know that it won't come - we, your customers - would not be so angry as a lot of us are now.

Take a look at

community.devexpress.com/.../345098.aspx

from my discussion.

And at the end the answer was:

->

2) As for missing features - we always suggest:

"That goes for anything you might wish to purchase: if you need

something now, don't be distracted with what might be available in the

future, settle for what you can buy immediately. "

3) We will do GANT for scheduler. But I can't give you any timeframe right now.

<--

This functionaliyt was on roadmap for 2011.1 on particualr systems. And now ther's no timeframe any more!

And that's the point which made me angry!

In other words: BUY ANYWHERE ELSE!

And yes, I'm now thinking about it!

Regards

Juergen

22 May, 2011
Dave Frank

I'll let my comments in the thread stand of course. I never said "WTF am I going to do now". I never even implied it. I clearly stated what I was going to do which was already the plan if the Scheduler didn't make it.

I was also perfectly fine with supports answer "they didn't make it" as I clearly stated. You made it a big deal, not me. I didn't even state it meant I was going to have to use a competing toolset until after I believe I was slighted. If nobody else had made a big deal out of it then the "it's not there" answers support accurately provided would have been the end of the thread. You chose to draw it out and now you chose to pick me out of the crowd with a false representation of what I said.

Truly disappointing behavior towards me considering I've been a loyal DevExpress customer since VCL Grid 3 and have carries subscriptions to both the VCL and DExperience Suites for several years now.

22 May, 2011
T Schoute

@Julian,

Sometimes a delay in a roadmap can happen, but I am waiting for 3 years now for something in your 2008 roadmap (www.devexpress.com/.../Roadmap2008.xml) and also you gave feedback that you are working on this feature (See your comment in this blog community.devexpress.com/.../sneak-peek-winforms-alert-window-gains-great-new-features-coming-in-v2011-1.aspx), eventhough the status is still "Accepted - Release TBD" (www.devexpress.com/.../A1194.aspx).

Can you explain how this could have been missed?

23 May, 2011
Rinaldo Ferreira Junior

Hi Julian!

I think we all agree that a Roadmap is not a set of promisses. The main point here is about communication. I am sure your team knows in advance when a certain feature won't be delivered so, if your roadmap is kept updated, I think people can rethink your plans on time.

One of the features on your Roadmap, the Theme Builder, is a central feature to my projects and now I know it won't be on the next version. If I knew this before my plans would be rethinked within a reasonable time frame but now it can't be that way.

Think about it. Communication is the word. If you make things clearer I am sure this kind of problem can be minimized.

Regards,

23 May, 2011
Jaime Alvarez [VOLUNDAT]

It´s easy,

Devexpress should be offer suscriptions by works finished

Vol.1 and Vol. 2.

If DX need one, two or more years to finish two versions,

we should be to pay just one suscription with two releases respectively.

One year suscription = (201? vol. 1 and minor releases and 201?. vol 2 and minor releases)

;)

Jaime Alvarez

23 May, 2011
Obliterator

The roadmap is very useful (to help justify budget for subscription and gain an idea of where the toolset is going).

I agree items on the roadmap are not set in stone, but people may base their plans upon them - so I would hope it represents a strong commitment rather than wishlist or simply best efforts. To be fair, I think you've delivered the majority of the roadmap successfully.

What would be helpful is to document the missed items upon release (to save people looking and getting frustrated) and crucially to list the status of that item moving forward. Has it been moved to 2011.2, or to 2012.1 or even has it been dropped completely. Also, what impact do these items have on the next part of the roadmap?

Communication of updates like this means people know where they stand and you wouldn't see these types of individual queries being posted in the first place. Incidentally, I don't think referencing individual's queries in a blog like this is helpful. I certainly would not have taken kindly to that.

Each release might be a good opportunity to review the roadmap. You could consider publishing a 12-month rolling roadmap updated twice a year, so we would now see 2011.2 and 2012.1 roadmaps.

Finally, I would agree the 'Accepted - Release TBD' ticket status is not particularly helpful when many items are left in this state for years. I now view that status as little more than "wishlist" until I see it appear in the roadmap. I would prefer better clarity in the accepted tickets regarding planned release schedule.

23 May, 2011
Michael Thuma

Road maps - remind me little of the idea of glassy development processes. The worst thing you can do is to show the status of a development, the result is guessing and promising. No one knows the future.

I can remember my first training on SAP/BW and a promised feature was not in the version 2.x (this means wait 4 years). People complained ... we promised our customers. Yes and yes, they promised and not the vendor. So I say if a feature does not make it into a release the world will not break down and for 6 months no one will recognize. Software lives long avg. 12 years and a few months don't hurt. 12 years ago ... What did we do?

23 May, 2011
Roger Areia

I am not sure the road map is useful. Psychologically we are going to base our decision to pay the subscription or not, at least partially based on the road map.  But I find more and more the road map is filled with marketing strategies rather the things we really need (although the two might be the same thing, they might not).  If we can not count on the contents of the road map (which we, really can not help doing - as we have no other information), is it useful for us?  On the other hand, I think it is useful for you.

And yes, we produce a road map that we will (in consultation with our customers and their changing needs) stick to.  This might mean scaling back on our promises when we write our road map...

23 May, 2011
Vadim Smirnov

You roadmap lack one important feature - BUG hunting.

Honestly, do less new features, but do it better. 2009 was good, but 2010 was full crap.

We already reported about several bugs, but even now, in 2010.8 version we still discover new critical situation about Instant Feedback data source again and again. Nowadays our programmers not even bother to reporting me about you errors. They just write code and comment it as "this is devexpress bug workaround".

24 May, 2011
Ferdi Botha

Hi Julian,

I think the feedback devexpress has received thus far from their customers regarding the roadmap should be sufficient for you to be able to make a decision as to how devexpress can incorporate more transparency and/or open proper communication channels when it comes to deliverables with their customers (whom we are). My opinion is the one key factor devexpress seems to be missing from what I have read thus far, and it’s that devexpress is simply not listening to their customers.

No, we don’t provide roadmaps to our customers, simply because there is so little time to try and map out the future for our products we offer, which is why we value the work devexpress has put into their suite of controls as it is a huge timesaver for us. That is again why I stress that I feel the products devexpress has available is mind blowing – however there is one critical factor which should not be forgotten or taken lightly – the customers (whom we are to devexpress) are the ones paying the bill at the end of the month; keep us happy and we will in turn keep devexpress happy by continuing our subscription renewals and doing more purchases from devexpress.

I fully understand that a roadmap is not a set of promises and that it’s hard for me to even comment on a roadmap since, we call ‘ours’ a simple FRL (Feature Request List), and yes we stick to our FRL, since our FLR is what pays our bill at the end of the month. As we all are developers this should be easy and logical: provide your customers to their needs, and they will provide you with yours. I however do have to say that I find it insulting – the way you have treated devexpress’s customers with your response to their cries ‘on this blog sofar’. Take note that 99% of my response sofar has not been personal and or insulting towards YOU but more as a bit of light for devexpress where they could take this up as the building fundamentals which should be: to seriously listen to your customers – as they are the ones coming back for more – as stated above some features have been Accepted – TBR for more than 3 years now - why?

I do understand that technology changes so fast that we have to try and keep up with it so that we could always have that competitive edge over our rivals.

Would it not be beter rather to just have a feature list request and ensure that devexpress does deliver on its promises – because if you think of it this way 90% of the development features devexpress receives are ideas and or requests from their own customers (whom we are – just a thought)?

I do understand that we also have to do marketing (to ensure new revenue streams) which is why a roadmap is brilliant, but one thing we all should have learned by now in this software age is that to sell ‘vaporware’ is almost as good as blatantly lying to our customers in their faces, and worst of all is that some do get away with it – I however find it arrogant that YOU then went and insulted those customers to whom ‘vaporware’ was sold – because they simply don’t understand that a roadmap is only a “wishlist” and or were we as a company (or what we intend to set our focus to) would like to be with our product(s) in 6 months or 12 months from now.

I have to stress again that I really value the products devexpress has, and rely on it solely for my development purposes, but I would not welcome any such response you have set out within this blog as I would feel that it would be insulting if it would have been me you were talking about.

Regards,

Ferdi

24 May, 2011
George Benecos

Man! It's that time of the year! Again! In only a few words: the "caveats" paragraph on the Roadmaps is 100% EQUIVALENT to the "Accepted – TBR" comment on the unresolved issues. That's it. If you find the solution to the one, you get the other for free as it is the same! For me, i stopped searching for a solution because there is not one. For me, both approaches is just the carrot that DevExpress throws to us to keep our interest high enough to renew licenses without making any promises.

24 May, 2011
Michael Thuma

Imho, the more carrots they throw the more I like them.

24 May, 2011
Holger Kammerer

I am with most of the comments. For us, the worst thing is, that many urgently needed issues are in "TDB" for years now, especially for XtraPivotGrid and XtraReport. If we do this with our customers, the next time they will take their software from another vendor....

If this situation will not change, we have to look for comparing tools in our next big release.

For many years i was absolutly satisfied with DevExpress (one of the first reviews on componentsource in 2006 was from me). But now i am going to lose patience. It's a great pity.

24 May, 2011
Hugo Barillas Quan

I'm a big fan of DevExpress, but right now I share the general fealing in the community: You are not hearing your customers. Worst, you are ignoring their complains again and again. No one wants to pay for a wishlist.

24 May, 2011
Neil Christensen

First, if you base the long term viability of your company or product line on what a vendor puts in a roadmap at the beginning of the year when hope springs eternal and even the Chicago Cubs still believe they can win the World Series, then you are truly insane.

Secondly, you aren't or at least shouldn't be paying for what's in the roadmap.  You pay for what has already been developed.  That's all.  DevExpress, as far as I know, doesn't run a futures market.  They don't say, we're charging $1,300 for this suite of products based on what we feel we're going to produce this year.  If you're buying it based on that approach you are setting yourself, your company, your products up to fail.

The roadmap to me is a marketing document.  I know they'll tell me it's more than that, but it even smells like marketing, so that's how I treat it.  There is absolutely nothing in the document that in any way tells me how they plan on getting from point A to point B.  There is no way I'd ever base a business decision on what's in this document.  It does, however, give me some indication as to what the availability of resources might look like as well as provide an overall sense as to any shifts in thinking that may be occurring going forward.  That's really all I could ask for.

Finally, I think you have to have had DevExpress components long enough to understand how this company seems to function.  I've used a number of 3rd party controls from a number of different vendors.  Not just looked at them, or evaluated them.  Really USED them, in REAL products.  They all love quantity.  Look, we have 1,000 WPF controls and our competitors only have 20.  Yeah, but they suck.  But we have LOTS of them.  Yeah, but they REALLY, REALLY suck.  DevExpress has the opposite problem.  The only thing that comes out is quality.  Even the Beta versions are quality releases.  The WinForms grid was/still is the single best grid I've ever used.  It's not even close.  I even embedded it in my WPF apps until I started having too many airspace issues.  The point is, if you're looking for new crappy bug ridden controls that are released at a rapid pace, ya ain't going to find them here.  Don't base your purchase on that.  Base your purchase on the quality of what's available TODAY.

Do they put too much in their roadmap?  Yes.  Are things in there that are very wishful thinking.  Yes.  Probably because "were going to keep making !$#* that doesn't waste your time or your customer's money" while a good marketing slogan probably doesn't sell a lot of new licenses or fill up the pages of a roadmap.  I blame marketing.  Even if I'm wrong, I'll still blame them. :-)

In the end, try some other controls from other vendors or open up VS, Blend and write your own...cause it's easy right?  Otherwise, read the roadmap ONCE, maybe twice if you get bored, and then get back to actually writing code that solves real world problems.  I find the blog posts, tutorials, etc much better indicators of where the ship may be heading anyway.  All this hand wringing over the roadmap is just background noise.

24 May, 2011
Andrew (DevExpress)

We would also like to stick with the Feature Request List (FRL) here. Unfortunately, in reality, you have to choose what you are going to stick to: the time or the feature list. I can only imagine what would happen if we delayed the release for a couple months based on some of the comments in this blog :-)

Let me explain how it works at DevExpress. We have about a dozen teams working on different products/platforms/features. When the code freeze date nears, we start removing all unfinished features from the current build, otherwise we would never release. If not, someone would just ask for a “week” more to let him/them finish that “cool” feature and we end up delaying the release again and again.

I fully understand your frustration about not having the SL Scheduler, for example. Nobody is happy with that: the team that works on the product, DevExpress as a company, or our customers.  The team responsible for this feature strongly believed that they could make it in time. We can all curse them. Outside of the team, it looks like they failed; and they did. No question about it.

However, what would you tell to your customers if two of your lead developers left in the middle of preparing for a major release? It doesn’t happen frequently here, but it did happen to this particular team. The rest of the developers were not able to reach the original goal. It won’t last long: the team will overtake their goal again in a couple months. The newcomers on the team will start being productive instead of taking time from the experienced members being trained. It just doesn’t happen overnight.

Something that isn’t mentioned: I believe everybody will find a lot of features in our What’s New that Julian did not mention in the roadmap. Did we hide them from the roadmap? No, we did not. At the time we discussed features, we did not think we would have enough time/resources to work on them.

24 May, 2011
Holger Kammerer

I understand, that a company has to get new customers. But you must not forget about the existing customers. In a limited market, if you do so, the customers talk with each other and in a short time you have a bad reputation. And then you will get less new customers and you lose the existing customers. Not from today to tomorrow, but time after time.

DevExpress has made a great job in the last years. But there is one is critical issue, everbody is talking about: the long lasting "TDB's". Make things clear to us - your customers - and everything will be alright. Change the TBD's to rejected, if you see, that a requirement is not anymore on the actual roadmap.

25 May, 2011

Please login or register to post comments.