In this interview with Artima, Ben Chelf said that spending more time on thinking of the uncommon cases would result in higher-quality code:

http://www.artima.com/lejava/articles/javaone_2007_ben_chelf.html

How much effort do you typically spend on thinking through the unexpected and uncommon cases your code may encounter?

I always try to think of all possible options of where the code can go wrong, but end up with the options which I know work well with my code. Then I give out my code to my colleagues for testing and they find me the bugs in the code.

Thinking of a way to do something that will (usually) work isn't that hard. What makes design hard is finding and avoiding the problems raised by the uncommon cases you're talking about. This is the core of design; why isn't it discussed a lot more often?

I guess this seems so obvious that I don't really understand why it would be posted here. I don't think many of the people that check out this site don't already know this. Am I wrong?

One of my favorite lines is to the effect of "any donkey write a program that works when everything goes perfectly. The trick is dealing with problems effectively."

The people that need to understand this are the managers that reward those who don't worry about anything but the 'happy path' because they seem efficient.

> How much effort do you typically spend on thinking through
> the unexpected and uncommon cases your code may encounter?

It's often probably 70% if not more of the time I spend coding.

>> How much effort do you typically spend on thinking through
>> the unexpected and uncommon cases your code may encounter?
>
> It's often probably 70% if not more of the time I spend
> coding.

Exactly. A designer's job is to provide a *working* solution to a problem. That doesn't just mean a solution that works *some* of the time. Would you buy a watch that told the right time eight out of every ten times you read it?

> I guess this seems so obvious that I don't really
> understand why it would be posted here. I don't think
> many of the people that check out this site don't already
> know this. Am I wrong?
>
What was interesting to me about this interview was his statement that a major source of bugs he has seen comes from people not understanding the interfaces they call into. That was his main point. So as projects scale, an important consideration is communication of how to use interfaces--or really, just what the interfaces actually are. Another thing he said that I thought was interesting was that you can find potential bugs statically, without knowing the semantic details of an interface, by looking for inconsistent usages. The last thing he mentioned was that he often sees bugs coming from not handling errors. So regardless of whether or not people who read this site know about handling error conditions, in his experience that's a main source of bugs.

> The last thing he mentioned was
> that he often sees bugs coming from not handling errors.
> So regardless of whether or not people who read this site
> know about handling error conditions, in his experience
> that's a main source of bugs.

And I see the same thing. I guess what I'm trying to say is that the kind of people that haven't figured out that error handling is important aren't really the kind that make a point to go out and read articles about how to write good code. Maybe there's a few that will but it seems a little bit like writing an article about how the protecting the environment is important for a Sierra Club member newsletter.

There are two things that annoy me to no end. Developers that ignore exceptions and/or error codes and developers that throw exceptions or return error codes for things that are no errors. The first forces me to have to tell people to always check for errors and never squash exceptions and the second forces me to make exceptions to that rule.

> I guess this seems so obvious that I don't really
> understand why it would be posted here. I don't think
> many of the people that check out this site don't already
> know this. Am I wrong?
>
> One of my favorite lines is to the effect of "any donkey
> write a program that works when everything goes perfectly.
> The trick is dealing with problems effectively."
>
> The people that need to understand this are the managers
> that reward those who don't worry about anything but the
> 'happy path' because they seem efficient.

I basically agree with what you are saying, but I think there are situations where sticking close to the happy path is appropriate. For example, prototyping when you really have no requirements. You are using the code as a vehicle for flushing out requirements, and at that point being cheap, malleable, and disposable are more important than being robust.

The problem, of course, is the manager who, in a stroke of brilliance, decides that a mockup intended for flushing out requirements somehow represents "almost done" software.

> > I guess this seems so obvious that I don't really
> > understand why it would be posted here. I don't think
> > many of the people that check out this site don't
> already
> > know this. Am I wrong?
> >
> > One of my favorite lines is to the effect of "any
> donkey
> > write a program that works when everything goes
> perfectly.
> > The trick is dealing with problems effectively."
> >
> > The people that need to understand this are the
> managers
> > that reward those who don't worry about anything but
> the
> > 'happy path' because they seem efficient.
>
> I basically agree with what you are saying, but I think
> there are situations where sticking close to the happy
> path is appropriate. For example, prototyping when you
> really have no requirements. You are using the code as a
> vehicle for flushing out requirements, and at that point
> being cheap, malleable, and disposable are more important
> than being robust.

Of course. I didn't mean to imply such situations don't exist.

> The problem, of course, is the manager who, in a stroke of
> brilliance, decides that a mockup intended for flushing
> out requirements somehow represents "almost done" software.

This is bad but I see scenarios where ostensibly expert developers deliver code as complete with major holes in their error handling, if there even is any. Often they are rewarded for doing so. When someone else comes along to fix things, they are often compared negatively to the original developer because they took so long to work on something that the original person completed so quickly. The manager draws the conclusion that the cowboy is much more efficient.

A lot of this comes down to managers that have not written code or were themselves the kind of developer that couldn't be bothered with error handling but mostly the former.

> This is bad but I see scenarios where ostensibly expert
> developers deliver code as complete with major holes in
> their error handling, if there even is any. Often they
> are rewarded for doing so. When someone else comes along
> to fix things, they are often compared negatively to the
> original developer because they took so long to work on
> something that the original person completed so quickly.
> The manager draws the conclusion that the cowboy is much
> h more efficient.
>
> A lot of this comes down to managers that have not written
> code or were themselves the kind of developer that
> couldn't be bothered with error handling but mostly the
> former.

It never ceases to amaze me how obsessed we engineers (I think it's worst in software, but it happens everywhere) are having our work declared done before we feel it is, or how convinced managers are that engineers most have finished a long time ago and are just busy goldplating their work.

In my personal experience I think this tends to happen because maintenance is "free," while project work is not. Free is good for the manager, because he doesn't have to pay for it. Free is bad for the developer, because he's working uncompensated overtime. Yes, there's uncompensated overtime within a project, too, but to the manager that's better used for features.

> It never ceases to amaze me how obsessed we engineers (I
> think it's worst in software, but it happens everywhere)
> are having our work declared done before we feel it is, or
> how convinced managers are that engineers most have
> finished a long time ago and are just busy goldplating
> their work.
>
> In my personal experience I think this tends to happen
> because maintenance is "free," while project work is not.
> Free is good for the manager, because he doesn't have to
> o pay for it. Free is bad for the developer, because he's
> working uncompensated overtime. Yes, there's
> uncompensated overtime within a project, too, but to the
> manager that's better used for features.

In some of the places I worked, managers' compensation (raises + bonuses) were related to annual goals such as getting XYZ project into production by a specified date. The managers naturally urged the software along before it was ready.

> In some of the places I worked, managers' compensation
> (raises + bonuses) were related to annual goals such as
> getting XYZ project into production by a specified date.
> The managers naturally urged the software along before it
> was ready.

At my last place of employment, a large project that could not be utilized for legal reasons was pushed into production so that the project could be declared a success. All it was doing was burning CPU cycles for quite a while.

I see it more as an Engineering tradeoff. Stipulating that function X only works properly when called with integers between 1 and 20, allows one to write shorter and more efficient code. Unfortunately tightly specified interfaces creates tight coupling. Balancing the tradeoff between tightly coupled, fast and short subsystems or loosely coupled, slow and complex is the challenge. The alternative is loosely coupled, fast and short that might blow up at any moment. Choose your poison carefully.

It would be hard for me to quantify as a percentage of time, but I can say that it is important. It's usually not done as a separate exercise, but as I'm coding and running through my own test scenarios.

The most common scenario for me is finding a business case that wasn't covered in the initial analysis. Usually I'm the one questioning the user on it.