The Circle Of Life

One of the funnier things about this profession is how so many things are cyclical.  Language mavens are fond of saying that every programming language eventually turns into a poor copy of Lisp, and every 10 years or so there is another format for encoding data so that the machines will have some ideas of how to process it (ASN.1 was XML before XML was born)

So I was tickled to read about Taco Bell Programming, where Ted Dziuba describes how to do web crawling and MapReduce with UNIX utilities.  It rang true, especially given the current situation at The Job, where new tech is being enthroned.  Then I found Mike The Coder's post about his reaction and Ted's response, which was even better.  I find new things about the OS every time I look, and there are great ways to do most tasks already in place.  But every generation needs to invent its own set of tools before it learns that much of what they want is already there,

It's almost like the end of The Wizard of Oz, where Glinda tells Dorothy that she would not have believed that the ruby slippers would take her home before she experienced the magic in Oz.

Heck, given the number of flying monkey's I've worked with, that's more apt that I care to think about.....

---

Why We Code (again)

(As opposed to Why We Fight)

I've always felt that there was a unique property of writing code that was not found in other professions - getting in the Zone, seeing the data in your mind, making a machine do your bidding.  It's something that I always like when I get the chance to write new code (a rare occurrence these days).  Debugging provides the thrill of the hunt, as an alternative to pure creation, for variety.

So I was greatly pleased to find someone else who considers himself Lucky to be a Programmer

Gustavo covers much of the same ideas that I have felt, and I'm heartened that an apparently younger programmer (or at least newer programmer) is still finding the same joys in the work.

---

I Can't Handle The Truth, Apparently

What a day.  After spending almost three weeks digging around a test system trying to find the cause of a communications failure, someone mentions that the test endpoint is prone to locking up.  Which causes the errors we were seeing.  And this just after getting an email from the developers of the test endpoint asking about some new messages in the API.  New, that is, 4 years ago.  Which they have not implemented yet.  Despite 2 revisions of the API since then.

Words fail me.

---

Duck, Duck, Goose!

A few weeks ago, I read this post about something called Duck Programming, and it rang a few bells.

I've run across a number of these systems in my career,and each has proven to be an abject failure.  It is simply not viable to make a complex system totally flexible without programming in some form.

The first system I ran into this was one for replacing single-purpose cellphone provider consoles in stores selling cellphones.  The goal of the system was to interface with the store's systems to provide all the options to sell the service without requiring a special-purpose console.  It was not simple, but we were well on the way to having this when we ran into the bete noire of cell phone sales - the service plans options.

It seems that at the time, all the cellphone service companies allowed their salespeople to define almost anything as a package, to allow them to make sales.  So even though I could not get just call forwarding as an option, a salesman could decide to offer just call forwarding to a customer if the salesman thought it was necessary to make the sale.  So every possible option had to be allowed, but only if it was defined from the cellphone service side.  And it had to be simple to set up.  No programming necessary.

Needless to say, we did not succeed.

The second time I saw this, it was a special-purpose language to control telephone switches, that was supposed to not require programming.  It didn't require programming, but required you understand trees and stacks, which meant that you had to have taken programming classes to get everything right.  We ended up replacing it with a database and C, which had the added benefit of allowing us to hire programmers from almost anywhere, instead of those who had happened to work in that system previously.

The third time was an attempt to replace a complex control system that had 4 main sections of data, each of which had numerous relationships, with a key:value store.  Everything was a tuple, and the keys connected everything in great transitive chains that taxed the system just to get the basic data out.
It failed as well.

I'm starting to believe that the Managerial class fears programmers the way that Bronze Age nomads feared blacksmiths - programmers wield mystic powers that shape reality, and are best done away with when you are done with them.

---

Legacy Code and New Developers

I just read this article about legacy code, and I am dumbfounded.  The author seems to embody the attitude that nobody before him/her was a capable programmer.

(Warning, Old Fart Programmer Rant approaching...)
What new programmers forget is that the legacy code was written over many years with evolving needs.  The original schedule was probably a Death March, there have been 4 major OS version updates, 7 compiler migrations, and a database vendor change in those years.  The customers have made thousands of change requests, all of them urgent needing immediate fixes that have to be tested on the customer site because they have a configration that cannot be duplicated in-house in less than 2 weeks.

There have been 20+ developers working on this, some of them contractors with less interest in long-term maintainability, some of them fresh out of school, and most of them overworked.

One of the systems this code has to interact with is ancient and does not use a modern communications protocol, so you have to write raw socket code and parse proprietary binary streams - no well-defined XML with a DTD here, bucko!

There are no unit tests, because 1) this code was written before Agile was invented, and 2) the project managers are old-school, and testing is not part of their schedule, it's for the Test Group, so you can't waste time writing tests during Development, or you get fired.



So don't get all holier-than-thou about old code, laddy - your code will look like this someday. if it's still in use.

---

Coding Quality and Your University Courses

All programmers are self taught - or are they?

The basic point of that post is true, at least in my case - my courses did little to teach me the details of good coding style and practice.  Of course (ha!) I also learned 5 programming languages in undergrad, so there was not a lot of time to get beyond the basics.

However, the courses also noted the building blocks of the larger concepts - modularity was handled in the first class via the "Karel the Robot" exercises - writing programs to make a small robot trace shapes.  This covered the idea of wrapping repeated actions in functions/subroutines to allow later re-use.

Pascal covered the side-effect in procedures vs functions

But the big thing I think that the courses gave me was the space to realize that I knew the right thing to do.  I was able to see the correct way by being allowed to do it wrong.

Case in point - I was taking a course that was taught in Fortran, and was waiting to turn in my program printout when the guy ahead of me in line asked if I would look over his program to see if I could spot the error in his code that was messing him up.

He told me that he knew BASIC already, so he was writing the programs in BASIC to get the algorithm right, then translating into Fortran for the grade - an excellent idea.  Then I looked at his code.  It was bad.  The first thing that struck me was that he was jumping all over the place, instead of having blocks of code in reasonable places.  IF X THEN GOTO 130 ELSE GOTO 200, instead of having the ELSE be a fall-through.  And so on.

I worked through his code to offer advice, but I don't know if he got the big ideas out of it.

But my main point here is that  if you go into programming, you should have the mindset to see the good stuff on your own - university education is to teach the things that your can't see.

---

Yet Another Rant, on Client-Server Roles

I fear that I am only writing posts here when I am pissed off at something.

However, that's not going to stop me from venting. :)

Ok, the topic today is communications programs, and a severe lack of understanding of a basic communications concept.

A typical inter process communications paradigm is the Client-Server.  One process is up and running, with a well-known contact point; this is the server.  Other programs, the clients, which can be short-lived, will connect to the server at the well-known point, send messages in, and the server will send responses.  In many cases, the server is single purpose, like the Network Time Protocol servers run on many large networks, to provide a consistent time signal for all the other computers.  But there is nothing that says a server cannot do other things as well.

But I ran across a developer recently who was confused by a program we have at work that is an intermediary in a chain of processes that communicate with external devices.  Due to the need for handling many external devices, this program uses an asynchronous protocol, where the messages going out are not responded to directly by the device, but at some later time.  So we have a zippered pair of protocols, where this program acts as a client to send a message to a device, and a server to receive the response from a device.

This developer was confused about this, noting that it was confusing that the one process was both a server and a client, when most were just one or the other.

I find it rather hard to believe that any developer with more than 4 years of communications programming work has not seen many, many examples of processes that talk to two or more other processes and act as client to one and server to the other.

I mean, is it just me, or is the idea that Client and Server are just roles a process assumes when it is communicating with another process, defined solely by who is originating the message?

The mind boggles.

---