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

The blogged wandering of Robert W. Anderson

Didn’t really get to IIW 2009A

iiw2009a_150.pngI didn’t really make it to the IIW yesterday, but I did make it to the dinner.  I hope to make it there by lunch today.

Instead of going to the IIW yesterday, I got pulled into a meeting to help work through some client issues.  The actual problems were completely tangential to my role on the project, but given my background I was happy to help. 

That morning meeting became contentious.  After the fifth time of hearing the same inadequate solution with a dose of attitude . . . well . . . I don’t cotton to that.

Kind of a mess, really.  I wouldn’t have done it at all except that I was helping out a friend.

And now, off to the IIW 2009A, day 2.

Tags: , ,

Losing the meaning of “Death March”

I have noticed a trend: a watering down of the term “death march”.

Robert Scoble is the latest to fall into it: blogging the reason his new show is delayed, he mentions that the PodTech Web team is on a death march.

Death marches (regarding software, anyway) are projects doomed to failure.

I’m pretty certain that isn’t what he means — if he did, I think Robert would be looking for a new new job.


Tags: ,

Frozen Code

Yesterday we achieved code-feature freeze for the Digipede Network version 1.3. There are a few remaining issues, significant testing (system, install, upgrade), and much documentation left. You know: software development.

Thanks especially to Mark and Jeff for meeting this internal deadline.

Now that we are through that I can spend some time on some other things. Dan and I have an article to write; I owe quite a few emails; more product planning, roadmaps, etc., . Oh yeah, and a vacation!

Tags: ,

0 for 8

I’ve been really out of the loop lately (hurtling towards a code freeze has a tendency to do that to me), so one thing I did tonight was to catch up on my reading. I was reminded about the The Eight Fallacies of Distributed Computing as enumerated by Peter Deutsch (thanks, Kevin Burton):

Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.

  1. The network is reliable
  2. Latency is zero
  3. Bandwidth is infinite
  4. The network is secure
  5. Topology doesn’t change
  6. There is one administrator
  7. Transport cost is zero
  8. The network is homogeneous

It is a classic. I came across this before at some point in my career when working on one of several enterprise and Web products I’ve worked on. I’d like to say that I kept this in mind when architecting the initial concept of the Digipede Network; however, I didn’t really.

It must have been lurking in the back of my mind, though, because we score rather well. We get a 0. 0 for 8.

Update for Dan: This is like golf. A lower number is better.

Tags: , ,

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