Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter rwandering on FriendFeed

rwandering.net

The blogged wandering of Robert W. Anderson

When is software development frustrating?

Last week I got into a morass on some prototyping I’m doing. I had made some changes to several different modules. I ran the standard tests: all good. I decided to run a slightly more obscure test (one that requires special orchestration). Failed. I wasted much time tracking this down. Turns out (of course) that the original code also didn’t work on my machine. Works every where else. In fact, I still don’t know what the problem is, but I’m moving on for now (confident that this problem will resurface somewhere else).

On Friday, my wife and I were talking about the week and I said that it was kind of frustrating. I gave her a little detail on the issue. Her response was:

That seems really common in your job (i.e., frustrating and non-productive time developing software).

That gave me pause. Is this common in my job or common in software development? Is it even common in my job?
Perhaps I have a tendency to talk about the frustrating without talking about the rest (the part that is creative and fulfills a need for artistic expression).

But, it got me thinking. What are the sources of frustration developing software?

Poor Tools / Development tools don’t work

This is generally not a problem; though I have a tendency to use addins from beta or early-access programs. Certainly while tools have been upgraded to work with VS2005, I’ve had a fair amount of uninstall / re-install / disable of addins. I wouldn’t bother, but some addins you just can’t live without (like TestDriven and ReSharper).

Of course the solution is to keep your dev machine fairly clean. Good idea, but hard to do in practice.

Too many manual steps

This is not uncommon when building something for debugging or testing on a remote machine. If between build and debug you have to switch to some other application, manually select files or folders, copy (ftp, . . .) files, restart something, run a test, wait for results, . . . then you have a source of real frustration and, worse, the chance of introducing error.

I try to root out manual processes as soon as possible.

Maintaining someone else’s poorly documented code or code with poor/nonstandard style

Not generally a problem at Digipede, but certainly can be frustrating.

Using poorly documented APIs

This can be frustrating for obvious reasons. One can easily get into a situation of just trying different things until the API works as you expect. Still doesn’t work? Try a different method or change this other argument. Combinitorics quickly can make this a black hole.

As an author of APIs, I know this can be hard to get right. How much documentation is needed? How many user scenarios are enough? How much knowledge should be assumed by the user of the product and other issues (like proper OS configuration, security practices, etc.)?

Other things that are frustrating?

What things am I missing? What frustrates you when developing sofware?

Tags: , ,

Paying for Good Enough

J Wynia posted about how Good Enough Often Is. He talks about an experience with a company a few years back where the president’s motto was good enough never is. I like his post.

I started my career at a consulting company (Quantum Consulting, Inc.). Then president, Bruce Smith, used to say that our customers weren’t paying us for perfection. This resonated with me for its pragmatism. As J Wynia puts it:

Fundamentally, good enough usually *is* good enough. After all, “good enough” means it met a set of requirements. It accomplished the goal. And, when reaching good enough costs $10 and “perfection” another $100 or $1000, it becomes pretty hard to make a *rational* argument for why we should pursue that particular perfection.

Of course, if you are launching people into space then spend the 10 or 100 times as much time and money to approach perfection. Otherwise, just strive for good enough. Good enough is often quite challenging on its own (and of course, doesn’t preclude greatness).

I say: strive for greatness, achieve good enough, and forget perfection.

Tags: , ,