Registered: Sep, 2005
Re: The Uncommon Case
Posted: Jun 12, 2007 12:29 PM
> > 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
> > know this. Am I wrong?
> > One of my favorite lines is to the effect of "any
> > write a program that works when everything goes
> > The trick is dealing with problems effectively."
> > The people that need to understand this are the
> > that reward those who don't worry about anything but
> > '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.