EppsNet

They were like spectators. You had a feeling they had just wandered in there themselves and somebody had handed them a wrench. There was no identification with the job. No saying, “I am a mechanic.” At 5 P.M. or whenever their eight hours were in, you knew they would cut it off and not have another thought about their work. They were already already trying not to have any thoughts about their work on the job.

— Robert Pirsig, Zen and the Art of Motorcycle Maintenance

We had a manager’s meeting today on the subject of employee recognition. The text we were given to read in preparation for the meeting was indistinguishable from a handbook on training your new puppy:

Behavior which is reinforced is usually repeated. . . . You risk extinguishing the positive behavior by not recognizing it. . . . Provide compliments in a timely fashion, as soon as possible after the event occurs.

That seems demeaning to me and it trivializes the work. I like to be recognized as a person who does good work but I also want to be recognized as someone who cares about his work. I know better than anyone when my work is good and when it isn’t. I’m not looking for pats on the head.

I said in the meeting that I’d rather try to motivate people by giving them the opportunity to do great work, to have some choices about what that work is, and to become the person they’ve always wanted to be.

I pointed out that we’re giving up our youth, our family — everything we hold dear — to come in to work every day, and if the work isn’t worth doing well for its own sake, then it’s a pretty poor exchange.

“We come to work to make money,” Manager A said, as though explaining something very obvious.

“We should sell off our lives one day at a time to the highest bidder?” I asked. “That seems like a good idea to you?”

“Do you really believe the things that come out of your mouth?” Manager B asked.

Manager C stated that in “the real world,” 99 percent of the people he knows are working their jobs for the money and, financial considerations aside, would rather be doing something else with their lives.

The highest-paying job I ever had — before or since — I quit after eight months. I didn’t have another job to go to; I just hated going in there in the morning and I couldn’t wait to go home in the afternoon. I never got a chance to do anything I enjoyed or anything I was good at.

I’m not doing this stuff to get rich. I am a programmer.

Thus spoke The Programmer.

• RT @RonJeffries: I can waste time in so many ways. How can I monetize this skill? #
• You don't hear a lot of FORTRAN jokes from cats – RT @sockington: 10 MEOW 20 GOTO 10 #
• Showed this video at an IT team meeting this afternoon. Good discussion on teamwork ensued. http://bit.ly/EAA0 #kicklikeagirl #

It’s done but we’re still working on a few things.

Then it’s not done, is it?

It mostly works, but it still needs a lot of testing.

How do you know it mostly works if it still needs a lot of testing? Isn’t that what testing is for — to figure out if it works?

I’m not making these up, by the way . . .

• prefuse gallery: http://prefuse.org/gallery/ #
• Processing gallery: http://processing.org/exhibition/index.html #
• Wordscapes: http://www.typotopo.com/wordscapes/ #
• RT @GLHoffman: NYC cabbie turns to passenger, after they both see huge crane fall off a building. “Fricking cranes.” #
• RT @Ben373: “Sh*t happens – when you’re around as*holes. ” Old truism from my dad. #

Here are 38 tips from the designer of the C++ programming language.

These in particular jumped out at me:

[5] Don’t try technological fixes for sociological problems
[8] Design processes to encourage feedback
[9] Don’t confuse activity for progress
[10] Don’t generalize beyond what is needed, what you have direct experience with, and what can be tested
[19] Use existing systems as models, as inspiration, and as starting points
[22] Design for change, focusing on flexibility, extensibility, portability, and reuse
[27] Keep it small. Don’t add features “just in case”
[29] Repeatedly review and refine both the design and the implementation
[31] Experiment, analyse, and test as early as possible and as often as possible

One thing that I resent about our computer culture is that they say we are nerds and that nerds don’t get along with people. I think that’s just insane. We are not just nerds — we are nerds, I mean, look at us! But we are not just nerds, we are like the priests or something in the Middle Ages, we are the Lords and Ladies of Logic. We are in charge of rationality for our era. We are bringing common sense and good practice and sound judgment and aggregated wisdom and glory to everyone.

That’s our job.

— Jim McCarthy

I posted this quote on a blog at work and IT people were calling each other nerds all day.

Good morning, nerd! How’s it going, nerd?

Being a nerd felt like, like being a hero — just for one day.

When you’re doing programming, you have to explain something to a computer, which is dumb. When you’re writing a document for a human being to understand, the human being will look at it and nod his head and say, “Yeah, this makes sense.” But there are all kinds of ambiguities and vagueness that you don’t realize until you try to put it into a computer. Then all of a sudden, almost every five minutes as you’re writing the code, a question comes up that wasn’t addressed in the specification. “What if this combination occurs?” It just didn’t occur to the person writing the design specification. When you’re faced with doing the implementation, a person who has been delegated the job of working from a design would have to say, “Well, hmm, I don’t know what the designer meant by this.”

It’s so hard to do the design unless you’re faced with the low-level aspects of it, explaining it to a machine instead of to another person.

— Donald Knuth, Communications of the ACM 58, 8 (Aug. 2008)

Q: What do you perceive as the greatest current challenge for software development managers and how do you help them overcome it?

The greatest current (and past and future) challenge for software development managers, and for all humans everywhere I suspect, is accurately perceiving reality and effectively accounting for it in their behavior. . . .

 

Q: What is your number one software project management tip, trick or technique?

Discussion should be illegal. Less talk, more code.

— PM Interviews: Jim McCarthy

Here's a really simple gliding tabs demo using glider.js, which is downloadable here.

As you can see from the really simple code below, you could do something pretty nice with this without too much extra effort.

Glider is dependent on the Prototype and Scriptaculous libraries, both of which are included in the glider download, as is the required stylesheet.

The average software developer reads less than one professional book per year (not including manuals) and subscribes to no professional magazines. These developers are not developing or advancing themselves professionally. About 75% of these people do not have a degree in computer science or a related field. They learn by trial-and-error and on-the-job training, which means that they risk learning other people's bad habits rather than industry best practices. This method of professional development perpetuates ineffective, inefficient practices that hinder the success of software projects.

--- Construx.com

A "spec" is close to useless. I have _never_ seen a spec that was both big
enough to be useful _and_ accurate.

And I have seen _lots_ of total crap work that was based on specs. It's
_the_ single worst way to write software, because it by definition means
that the software was written to match theory, not reality.

So there's two MAJOR reasons to avoid specs:

- they're dangerously wrong. Reality is different, and anybody who thinks
specs matter over reality should get out of kernel programming NOW.
When reality and specs clash, the spec has zero meaning. Zilch. Nada.
None.

It's like real science: if you have a theory that doesn't match
experiments, it doesn't matter _how_ much you like that theory. It's
wrong. You can use it as an approximation, but you MUST keep in mind
that it's an approximation.

- specs have an inevitably tendency to try to introduce abstractions
levels and wording and documentation policies that make sense for a
written spec. Trying to implement actual code off the spec leads to the
code looking and working like CRAP.

The classic example of this is the OSI network model protocols. Classic
spec-design, which had absolutely _zero_ relevance for the real world.
We still talk about the seven layers model, because it's a convenient
model for _discussion_, but that has absolutely zero to do with any
real-life software engineering. In other words, it's a way to _talk_
about things, not to implement them.

And that's important. Specs are a basis for _talking_about_ things. But
they are _not_ a basis for implementing software.

So please don't bother talking about specs. Real standards grow up
_despite_ specs, not thanks to them.

Linus

After three months on the dole, I got a job offer from the IT director of a local non-profit healthcare association here in Orange County. I start next week. As Gerald Ford used to say, "Our long national nightmare is over."

It's a small IT group -- 8 people, including the director. I've got to admit I'm a little burned out on big corporate IT shops.

I got out of hands-on programming and into leadership roles because I thought I could do a better job than the people I saw doing it. I wanted to develop teams that got things done using their skills and their collective intelligence, but in practice, you typically get locked into some corporate process standard.

A process may be good for delivering consistent results, but they may not be consistently good results. Like at McDonald’s, every Big Mac is just like every other Big Mac because they have a process for making Big Macs. But is a Big Mac a high-quality dining experience? Not really . . .

A friend and former colleague, who was also recently let go by a local mortgage company, emails to say

I'm doing well... still spending a lot of time in Bakersfield, spending time with my parents. I've been looking for jobs, but haven't applied for anything. I guess I actually need to apply.

She's single, she can afford to be sanguine.

I was in contact with at least 100 companies in one way or another – sent a resume, called, phone interviews, in-person interviews – and got two job offers. So the upside with her approach is that I could have avoided 98 rejections.

Did I mention the job is with a healthcare organization? I was laid off from my last job, with a mortgage bank, when the mortgage industry tanked. Prior to that, I was laid off from a dot-com consulting company when that industry imploded.

I've got a knack for getting into industries at their absolute zenith, then riding them down the drain.

But healthcare -- it's recession-proof! Isn't it? You can't say, "I'm going to put off getting critically ill until I have a better read on the economy."

You might wonder whether the Linux operating system provides evidence that offshoring can pay off. I had often wondered about this point myself, so I put the question to Linus Torvalds, founder of the Linux project. Torvalds replied that the two models of software development aren’t comparable:

I don’t think the Linux model works for offshoring in the commercial sense, or really ends up even being very relevant. The problem ends up being communication and the mental model pretty inherent in offshoring.

My belief is that when you say "offshoring," you very much mean "control the project on one shore, work on the other." That is, the implication of the offshore work being "subservient" is very much there in the notion of offshoring.

In contrast, the Linux model (and open-source in general) is that there’s no one-sided control, and that when work gets done overseas, it gets done because it makes sense to them, not to "us." There’s no control of one end over the other--both shores do what they want to do. The fact that makes it all work out is that, in the end, everybody tends to have somewhat overlapping goals.

--- Norman Matloff, "Offshoring: What Can Go Wrong?," IT Professional, vol. 07, no. 4, pp. 39-45, Jul/Aug, 2005

The Big Picture

We're going to build application that takes RSS data -- specifically the EppsNet.com feed -- as input, and outputs a VXML file that can be read and spoken by a VoiceXML browser.

The RSS Source Format

The general structure of the EppsNet feed -- or any RSS 2.0 feed -- looks like this:

Each item within the RSS feed has a format that looks (slightly simplified) like this:

VXML Output

Consult the VoiceXML 2.1 specification for more details, but the output we want will look like this:

What this will do when processed by a VoiceXML browser is:

1. Say the title of the RSS feed.
2. Offer the listener a numbered list of post titles to select from.
3. Parse the user's selection, by either voice or touch-tone input.
4. Read out the selected post summary.
5. Clear the input variable and offer the opportunity to select another item.

Generating VoiceXML from RSS

Because this is a WordPress site, we're going to use PHP for the task of converting RSS input to VXML output. To simplify the task of parsing the input, we'll use MagpieRSS, an RSS parser written in PHP.

The main loop in the code below processes up to 5 RSS items and simultaneously builds up two strings, one for the selection prompts and one for the item details.

Try It

I put the PHP script at http://eppsnet.com/lab/vxml but the output is not very interesting in a regular browser. Fortunately, Voxeo offers a free service that maps voice applications to phone numbers. You give them the URL of your voice app and they'll point a phone number to it.

So -- if you pick up the phone, call 800-289-5570 and enter PIN 9992002320, the Voxeo application will fetch the VXML output from our PHP script and read selected excerpts from the EppsNet feed to you over the phone.

Try it!

Limitations

The VXML output doesn't contain the entire contents of each post, just the truncated version from the RSS <description> field. I tried using the <content:encoded> field instead but some markup constructs choked the Voxeo application. I think I could get it to work if I spent enough time on it, but for now, I've decided to leave it as an exercise for the reader.

My first 10 years in the software business, I had great managers. They did the management thing and I did the programming thing and we got great results together.

Then, after the dot-com boom torpedoed industry hiring standards, I got tired of working for managers who should not have been allowed anywhere near a software project, people who were not fit to direct a professional software developer to a table at the Olive Garden, much less direct their activities on a complex project.

I couldn't possibly have continued to work for people like that -- it just made a mockery of all the work I'd done over the years to actually learn something -- but I still miss being a developer . . .

Thus spoke The Programmer.

I ponied up the 50 bucks to join the XNA Creators Club and so far I've been able to code and deploy some rudimentary 2-D games on our Xbox 360.

"Can you program a football game?" my son asks.

"No . . . first of all, I'm just learning this stuff, and second, you can't expect one person to duplicate the efforts of dozens of people over a period of years."

"Haven't you ever heard of The 300?" he shouts.

"Yeah. They all died."

"But they gave a valiant effort!"

I'm rereading parts of The Psychology of Computer Programming and I notice that several of Weinberg's "food for thought" questions at the end of each chapter would be good questions to pose to a hiring manager:

1. How long have you been in charge of your present group? How many of the original people remain? How many people have left and what were the reasons for their departure? What sort of provisions do you make for this kind of turnover?
2. Describe the sequence of work planned for your current project. Is the actual work proceeding according to the original plan? Do you expect it to continue in this manner?
3. How close is your progress reporting scheme to the reality of the work that goes on? What checks do you have to find out if it corresponds to reality?
4. What is your impression of what motivates your staff? Is it the same for all of them?

I saw the following attributed to Ralph Johnson. I'm not sure if that's the Gang of Four Ralph Johnson, but it probably is:

The problem is that almost all software schedules and budgets are bogus. They are created for political effect and have little relationship to reality. Thus, whether they are met has nothing to do with the people working on the project.

Who makes your schedules? Project managers? They are almost certainly the wrong people. You can't predict how long something will take unless you are an expert at doing it. The programmers? Are they allowed to say "we don't have enough information to make a prediction"? Are they ever told "that is too long, you'll have to do it in six months"? The only way to get honest schedules is from people who have experience in doing the work who know that they need to get the schedule right and not under or over-estimate.

I asked an IT VP the other day why he thought every project in the company is late, and he said, "Bad estimating."

No . . . there's a difference between bad estimating and dishonest estimating. If we were dealing with bad estimating, I'd expect to see estimates all over the place, including some way too high and some way too low.

"Man, that's some bad estimating!" I'd say.

But when every estimate is too low, that's not bad estimating, that's dishonesty. It may be forced dishonesty, but it's dishonesty nonetheless.

Thus spoke The Programmer.

Somehow we've got it in our heads that every programmer in India is good, fast, and cheap, and every programmer in the United States is lousy, slow, and expensive. My theory is that for version 1.0 of a product, the maximum allowable distance between the engineers and marketers is thirty feet.

--- Guy Kawasaki