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

The blogged wandering of Robert W. Anderson

And now we scheme

It is refreshing that Scheme (the variant of Lisp) is getting so much attention right now.

Check out for Scheme resources (thanks to Steve Maine for the pointer).

It was used as a teaching language at Cal. Scheme was, without a doubt, the only mind-expanding programming language I’ve ever had the pleasure to ingest learn and use.

Tags: , ,

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: , ,