Reading the minds of all clients and users

[clintonia]

Hi again everybody,

I'm wondering what the general consensus is for trying to determine
all the things that could cause a bug in your application. I created a
pretty complex (at least for me at the time) app for a client and have
recently put it on a different server for beta testing. I told the
client that the testing site is for them to put the app through the
rigors of what they do so that I can iron out any bugs. I got this
response from the client...

"Honestly - I don't have the time to test every feature with every
possible scenario that can take place. That is what I am paying you
to do. I can check it out on the basic level but then I guess we just
have to test it in the real world."

I'm not even going to get into the complexities of the functionalities
(all I heard when I first developed it was, "It depends if..." for
EVERY situation). Now, is it our responsibility as developers to wrack
our brains trying to figure out every single plausible situation an
individual user may put the app through?

I do test it, but only with the information I have and in the
situations I can predict...which, apparently, is not EVERY situation.

Thoughts?

Regards,
Clint

p.s. Mike G, I tried to post this on discuss.cfphp.org, but it was
down.

[Michael Girouard]

I generally find that the brittleness of an application is directly proportional to the complexity of the API. In other words, the more complex your application is, the more brittle it tends (or seems) to be.

It is a good idea to schedule regular code audits into your development cycle. For example, every Friday an hour or so before I close everything down, I look over the code that I've written for that week. Whenever I find something that I don't like or anything I think can be better written, I make a note of it in my notebook.

I suppose it's important to mention that just because an application is large or has piles of logic, doesn't mean that your code has to be complex. Programming is about wit and cleverness. Before writing any code, think about the problem you are trying to solve. How can it be broken into small components? Each one of those components should become a class or series of classes.

Code duplication is a big contribution to complexity and brittleness of an application. If one part of an application is updated and another is forgotten about, errors will surely occur.

Consider giving test driven development (TDD) a try. It sounds like a lot of extra work, but it will save you a lot of headaches in the end.

Finally, see if using a framework is an option. Aside from speeding up development, frameworks force a developer to code a certain way all the time which produces nothing but consistent code.

If you're up for it, lets talk about your app during our next meeting.

Hope this helps,
Mike G.

mgir...@gmail.com
386-503-3505

Me: www.lovemikeg.com
Us: www.cfphp.org

[Jason]

While I agree with Mike on the topic of test driven development, that
will not always identify every bug. The whole idea behind beta test,
user acceptance testing, whatever you want to call it, is to determine
if the application is working the way the users expect it to. Your
user's should not be identifying bugs in your code but they should be
identifying any bugs in the business logic, workflow, and overall
usability. If the users / owners of the site do not wish to conduct
any UAT then they should acknowledge the fact that they are accepting
the possibility of these "bugs".

Jason