« June 2005 | Main | August 2005 »

July 29, 2005

Thumbs Up: Nextweb

A customer at the very far edge of DSL availability (on a 192k/128k profile, but not even getting that) finally had this horrible circuit go down for good. In a panic to have email working, I installed a router with modem backup, and they operated their office network on dialup for a week while we evaluated other options. That sucked beyond words.

A T1 is expensive and takes weeks to install, and it doesn't seem that cable internet was available. But I'd gotten a cold call from a fixed wireless ISP sales guy about two weeks before, and I figured there was no harm in looking into this as well. I was generally skeptical about wireless internet, mainly out of ignorance.

A lot of pointed questions and reference checking later, plus the on-the-ball responsiveness of the sales team, we decided it was worth a try. We ordered one megabit symmetrical service from Nextweb for $249/month, with 24x7 support and a reasonable SLA. It includes 5 static IP addresses.

One day later the techs were onsite, installing an antenna on the roof pointed at a local water tower that had their base station. A few minutes after I showed up I had plugged in the IP address information to our router, and we were up and running.

The tech temporarily left the service uncapped to demonstrate what the service can do: it's amazing. Running a speed test at BroadbandReports:

[Dude! Fast!]
Dude!

This is strictly temporary; the circuit will be turned back to the paid-for bandwidth, but it was very helpful to see that we're not on the fringe of coverage, more speed is available if needed, and that there is plenty of margin for us. We're seeing six millisecond latency to the first hop.

There is nothing about this service that has not been absolutely superlative: the sales team, installation team, and the technical performance of the circuit. It's been running for 18 hours now with not a single dropped packet that I can see. None of the IP addresses is on any spam blacklist either.

Only time will tell whether this plays out for good or not, but I could not be more encouraged about a technology I've just become familiar with. A big thumbs up to Nextweb (especially Alan, the sales guy); I'm looking into them for several other customers.

Posted by steve at 07:00 AM | Comments (1) | TrackBack

July 14, 2005

Uptime: 12 hours...

# uptime
 10:28am  up 12:30,  1 user,  load average: 1.00, 1.00, 1.00

... plus 497 days

... plus another 497 days

A Linux machine (100 MHz Pentium) I've been using for a nameserver has just rolled over the 497 day uptime counter twice: 

$ datemath 'today - ( 497 * 2 )'
10/24/2002

I wonder what I was doing then that forced a reboot?

Posted by steve at 09:47 AM | Comments (1) | TrackBack

July 04, 2005

Agile Programming: How to doom your software project

This morning, Kasia pointed me to "Agile Programming", and her take was that it was yet another buzzword. Looking into it, I find that it's more than that - it looks like a roadmap for running a project into the ground. And nobody would know why.

Reading the Manifesto for Agile Software Development we see a list of lovely platitudes that sound so nice, but hide a sinister reality.

• [We value] Individuals and interactions over processes and tools

Obviously we want to treat team members with respect and bring out the best in everybody, but those interactions have to be minimized as much as possible. Brooks' Law says that adding manpower to a late software project makes it later, and this is because of the exponentially increasing number of communications channels.

Tools and processes are fundamental sources of quality, and though of course it's possible to saddle a team with lousy tools, good tools offload much of the tedium and allow the team to expend its energies on things that matter.

Of course, no programmer is an island, and an awful lot of hard problems are solved not by a good tool, but by two developers chatting over coffee. But I think that a lot more projects have been sunk by not-enough-tools than by not-enough-interaction. I doubt many have been sunk by not-enough-people.

• [We value] Working software over comprehensive documentation

I can certainly see where this comes from, and it's hard to argue that if the software doesn't work, it doesn't matter how good your docs are. But professional developers revolve around the specification: without a spec, the developers are just hacking at code without a common purpose. This works great at the beginning (lots of progress) but goes downhill very rapidly.

The best way to appreciate the value of a good spec is by doing a project without one.

Furthermore, I have long held that "it works" is not the sole metric of software project completion, or even the best one; there are real qualitative differences between various kinds of "working" code, and anything that encourages "but it works" responses is saying that quality doesn't matter all that much and that all developers are created equally.

• [We value] Customer collaboration over contract negotiation

This has a "forget the spec, just start programming" smell that frightens me. "Contract negotiation" is not just deal-making and paper-pushing: it's deciding what the customer wants. Not only does the development team have to know what the customer wants, but the customer has to know too, and the very fact of going through "contract negotations" helps set the plan for the whole project.

Some years ago, a customer wanted me to build a large software system, and they wanted me to "just start programming". In spite of their desire for "customer collaboration", I insisted on writing a formal specification. Several weeks and 100 pages later it became clear that the project was well beyond what my customer could afford, so it was scrapped. My pushing back and forcing extended "contract negotiations" saved my customer an enormous amount of time and money.

• [We value] Responding to change over following a plan

When I see "a plan", I think "a specification", and anything that gets away from this is trouble. I think it's self-evident that change will happen during a project: sometimes external factors change the requirement, sometimes the customer didn't really think it out clearly up front, or perhaps somebody just had a great idea partway through the project.

Hopefully one has built a system that tolerates change, but one cannot send the message that change (especially late in the game) has no costs, or at least costs no more than change early in the game. Going through a round of "OK, let's find out what you really want in this change" not only nails down the details, but it creates a climate of taking change seriously.

In fairness, when one reads Principles behind the Agile Manifesto one does find good points: stepwise refinement has been a great idea (at least) since Niklaus Wirth wrote about it in 1971, and fostering teamwork is essential to any project. And any project that doesn't involve the customer on an ongoing basis is doomed.

But the whole "Agile Programming" idea seems (at best) a platitude fest, and I don't see how any actual professional software managers could have participated in this silliness. Looking at the manifesto, I can't help but believe that more projects have gone south due to following the warm-fuzzy festo points in favor of professional software-development disciplines: why would anybody want to encourage this?

And I wonder what Joel would say about this?

Posted by steve at 09:06 AM | Comments (6) | TrackBack