A request for simple example programs

08 January 2009

I got a worried call from support this morning. In essence a customer had provided his entire application solution as an example program to reproduce a bug and they wanted a nice way (British, with a cup of tea and a ginger biscuit?) to turn his offer down and ask him to please isolate the issue in a small project.

Cup of tea and a biscuit I'm sure I'm preaching to the choir here, but it seems to me that part of the job of a programmer is to debug. We never write perfect code every time (if you do, I'll gladly fly out and pair with you to see how you do it). We always make mistakes, and I'd vouch that part of the fun of programming is seeing a bug and isolating it and slapping one's forehead in a duh! moment and then fixing it.  I'll admit my particular programming blindspot is conditionals with multiple boolean expressions (one reason I like Refactor! Pro's ability to break conditionals apart and merge them back together: I can "see" that a simple boolean expression is correct).

Also programming these days is very different from when I were a lad (cue stories about shoeboxes in the middle of the road, travel to/from school being uphill both ways in the snow, etc). No matter what programs we write we are relying on external code, be it the operating system, database engines, run-time libraries, controls, frameworks, etc and in general a lot of effort has gone into that external code to test it and make sure it works in as many ways as the designers could foresee.

In the vast majority of cases where there is a bug in our controls, we find that it can be reproduced in a small project. Ach, put it more generally: in the vast majority of cases where there's a bug in some external code, you'll find it can be reproduced in a small project. But in some majority of cases where you see a bug, you'll find it in your own code as you build that small project.

With a small example project, it is much easier for us to verify that the code that calls ours is valid, that the way our controls are being used is as recommended, and so we can concentrate our resources on the problem area. It takes us less time to read and understand the code that isn't ours, to see that the bug isn't in that. Sometimes the bug may be from using the control in a way we hadn't foreseen and we can then more easily suggest a workaround, investigate a design/implementation change, or just reinforce in the documentation to do things the recommended way.

By providing us with a large project, it's virtually impossible for us to isolate the problem in our code. Well, not impossible per se, but more long-winded and resource-intensive. Given the choice between finding a bug in a small example versus a complete project in development, which would you rather investigate first? Uh huh, me too: the small one. There's more chance of a quick positive hit, of sending the customer away with the warm fuzzies, of getting that feeling of satisfaction of successfully completing a debugging session. Heck, given the choice between 10 small examples that repro different bugs and a large project that shows one, I'd rather debug the 10 small examples, bam, bam, bam.

The other problem with a large project is that the probability of the bug being in our code reduces dramatically. In effect, we then become the debuggers of your large project and in doing so we naturally don't have as much time or resources for other customers.

So, please don't get offended if, having received a large project, we ask for a small project that reproduces the problem. With a small program, we'll be able to confirm the bug faster, queue it up for fixing faster, get the workaround or the fix to you (and everyone else) faster. Everyone wins. With a large one, it clogs up the system. Help us help you get perfect code.

22 comment(s)
Nate Laff

I agree with this... unless it's an XAF app. I've submitted the same XAF app several times. When the error occurs in the underbelly of XAF, and the stack shows ALL DX code, I submit the thing. I couldn't give you the ratio of times it was something I was doing, or something XAF was doing weird, and in probably 90% of those cases, couldn't be reproduced by a smaller application.

Once I watch the trace go into stuff that I DON'T change (DX source, yes, I have it, but we've all discussed the challenges of rebuilding that source) I send the whole XAF app in.

8 January, 2009
Rory Becker - DevExpress

The other Major advantage of creating small projects to demonstrate an issue, is that it really helps to concentrate the mind. Very often one will see that the error is in fact in ones own code.

8 January, 2009
Nate Laff

Here is a good example of what I'm talking about (only Julian will be able to see it..)


Ignore the top for the most part. Look for when it was reopened in December. I tried to reproduce the issue with a whole new application. Couldn't happen. Presumably my code, right? WRONG! :)

8 January, 2009

One good exception to this is when we step into several bugs at the same time (say 7 or more issues) and then sending the whole solution would make more sense than breaking it down into tiny pieces!

8 January, 2009
Click Zimmerman

What about meeting your customers half-way?

<Slightly tongue in cheek mode>How about DevExpress starts including comments in it's shipped source code and we'll make the effort to simplify any example programs?</STICM>

I much prefer to work things out for myself and if the DevExpress source was commented I could probably solve most of my support queries myself. But, with the uncommented code, it's just easier to bug you guys for help.

8 January, 2009

I need to reinforce what I stated above. Lets face this situation: I am testing a new version and I find 8 different bugs which do not happen in a previous version. Does DevExpress expect us (the customers) to spend hours (most probably days) to build small projects, where as sending the whole solution is so faster? Honestly that sounds to me a little be awkward and odd...I understand your support has tons of issues to deal in a daily basis, but we (customers) have our own issues to deal as well, if the solution clearly shows bugs that happen in this new version that would not occur in the last version available, I really see no problem at all in sending the solution.

9 January, 2009
Gary Short (DevExpress)

Shoeboxes in the middle of the road? Explain.

9 January, 2009
Scott Blood

Ahhhhhh shoeboxes in the middle of the road :)

Its from a monty python scetch, it goes something like There were a hundred and fifty of us living in t' shoebox in t' middle o road (in a yorkshire accent).

9 January, 2009

man, I HATE debugging entire application solutions, even if the client reports 7 (or more bugs) in it. Better have 7 small examples that repro each bug. Yes, it is easier for the client to send me the whole monster, but I can't agree he will "... spend hours (most probably days) to build small projects...".

But hey, that's nothing compared to this: I got a support ticket from a client with just a few words - '..see the attached file that explains the problem'; I download the attached ZIP; there's a word file in it; I open the file in MS WORD; there are multiple screenshots in the document, showing some code-behind (say, 1000 lines of code-behind).... Now, go find the problem :-) :-) :-)

9 January, 2009
Adam Leffert

I agree that small projects are the way to go with bugs in individual controls.

When I run into what looks like a bug in XAF, I isolate it into a small project whenever possible, for the reasons you give.

However, I have also found that the worst (most time-consuming) bugs in XAF are not reproducible in smaller apps, and it will literally take days to try to isolate them.

More accurately, I will spend days trying to isolate them (as I have done), then give up and switch to trying to program a workaround.

The bug may or may not be in XAF.  If it turns out to be in XAF, I may NEVER be able to isolate it, which is why, at some point, I have to give up and submit the whole VS solution.

For example, I spent a billable week trying to isolate B132252 before I gave up and sent the big project.  The bug was 100% reproducible in my app by stepping through the code, and as the previous poster said, the crash was deep in the bowels of XAF.

So I personally promise to spend at least one whole day trying to find the error in my code before submitting large projects.

I'm not perfect.  DX is not perfect.  We're all trying our best.  So what's my point?

My point is that DX needs to make the XAF RWA a reality ASAP.  If I were in charge of XAF, I would choose someone and tell them to just pick a domain for the RWA, create it, and post it, live on the Web, with source code, no password, before 1/19/09.  Just do it.  Whatever gets done, gets done.

Allow the customers to submit feature requests and bug reports via the Issues db.  Let's all roll up our sleeves and get it done.

I spent a billable week trying to isolate B132252, which turned out to be an XAF bug.  Then I spend a few more days on programming the workaround, being careful to mark my code so I could remove the workaround when the bug was fixed.  Once the new version was released, I had to tweak almost all my DetailViews and ListViews to undo the workaround.

If the RWA existed, it would have broken when it was upgraded to the version (8.3.2?) that caused the bug, and it would have been fixed.

Could you please weigh in on my discussion with Dennis here?


Dennis says the scope of the RWA is to show each XAF feature.

I know that we need much more, as I describe in my post there.

If the RWA were real, I believe it would cause a major reduction in the number of XAF bugs which cause XAF developers to throw their hands up and submit whole projects.


Adam Leffert

9 January, 2009
Julian Bucknall (DevExpress)

For elucidating the shoebox allusion: www.youtube.com/watch

9 January, 2009
Garth Henderson

It would be very helpful (for both DX and us developers) to have a reference RWA for developers to change a couple of lines in to reproduce their problem.  A reference RWA would also provide a platform for consensus (DX staff and developer community) on best practices.

The Code Central examples are wonderful however they would have much greater value as part of a RWA.

DX and its collaborative community are definately leading the technology pack in trying to make a complex business application architecture better.

Maybe a couple of developers would be brave enough to  submit apps as RWA candidates that we can start with.  

9 January, 2009
Lars Christiansen

Just thought.. It seems we are all more and more relying on our customers to debug our code... doing the hard work.

9 January, 2009

Well PaulG, I understand your point and I totally agree this kind of S.O.S is rather not productive. However, when we here send a "whole monster" we try to make it as clear as possible, indicating a complete repro procedure. Usually we also send videos to shed even some more light on how to reproduce the(s) issue(s). I cant speak for you, but we just cant (unfortunately) afford spending a long time building different solutions for each one of the issues that come along when a new version is released.

9 January, 2009

Lars is completely right when he states that. We here develop software as well and we struggle to eliminate all bugs before a new version is released. However, when any of our customers finds an issue, its up to us to spend hours reproducing the whole situation in which the customer has stuck in, not the opposite!

13 January, 2009
.NET Developer

Good idea.

In fact, I would actually prefer to request Dev-X to upload their own working sample applications rather than having to debug my own.

15 December, 2012

I just want to add , that we all feel the same way, looking for solutions...

Now devExpress knows how do we feel when they release new controls and the demo is exactly the same as when we send our code to them, "Hard to follow" ? and we can say the same on our end  ... small samples please...then is much easier to follow no ?

Just a though!

4 March, 2013
Steve Mol

I've got to go with Raul on this one.  Most of the time, when I hit a stumper, it works fine in a small "example" project, but not in the real project, which incorporates databinding, et al.  So, if I can't see where the problem is happening (other than that it is apparently happening within a dx control), it could take hours, days, even weeks to find a way to create a "small" project exhibiting the problem.

If I could afford it, I'd get the source-code plans and then be able to debug it myself.  (Then I'd simply send the "fix" along with the bug report.)  Bit that level of subscription is far out of my reach.

So, I try to send the least amount of code I can - but still from the entire project.  But sometimes, that IS the entire project.  At those times, I'll specify exactly which page to load and how to reproduce the problem, hoping that dx has the required access to dx source code to see where the interaction is failing.

Simply put, sending a small "example" project is not often possible.

24 March, 2014
A Dev

I add my voice to Raumnz.

I would love to see demos in small individual projects. Adding all demos in one project complicates the entire project and makes demos so dependent...not easily understood or easily replicated.

It should be two way relationship, not OneWay ;)

Keep the good work.

27 October, 2015
Arianit Krasniqi

Garth Henderson has given the best solution!

24 January, 2018
Douglas Lynn

My problem is that simple projects often do not represent the complexity of the application, so the bug is very difficult to impossible to duplicate with a simple project.

7 February, 2019
4T Sistemas

I totally agree with commentary from RAUL TORTINA and DOUGLAS LYNN. We spend weeks maybe months to develop an application with DEVEXPRESS components. And suddenly in an update, some components that are running normally, stop working. But our projects are not easy to create a smaller-scale model for error replication. Maybe a support remotely would help a lot, both us developers especially when the subject is related to version upgrade.

9 April, 2019

Please login or register to post comments.