This tweet got a lot of likes and replies, so I should expand on it a bit. Most of the replies were additions to the list: Visual Basic (tool for automating and scripting Windows), Microsoft Access (great for small databases), PHP (which unseated Perl as the powerhouse of the web). But some of the replies were the things I deal with a lot: Explanations why my choices suck and I should choose other things.

I'm mature, experienced, and confident enough so that now those comments don't bother me, but it's a problem for novices in the tech community. Learning is difficult and frustrating, and hearing that the effort taken to learn a technology is worthless because that technology is "bad" is demoralizing and can lead to people leaving tech altogether.

So, let me help you cut off some of these discussions:

X is Dead

• X is obsolete
• X is outdated
• X is dying
• X is dead

No, it isn't. Technologies don't die easily, and I can assure you that once a technology has left the technology journalism circuit it will continue still for quite some time.

• FORTRAN, one of the oldest computer languages, still has new projects being written in it, and indeed had a new specification come out in 2008 which adds concurrency and a new spec being planned for 2018.
• New games are being written for the NES, Commodore 64, and Atari 2600.
• Flash is still ubiquitous, despite being declared dead in 2007.
• Operating systems abandoned by their parent companies (or whose parent companies are dead) still have devoted communities, and even active development (BeOS is now Haiku, Solaris has Illumos, and even Windows XP has ReactOS).

What they might mean is "X is no longer a way to be successful", which is also mostly false depending on how you measure success: If you want to make VC money, that is probably true. If you want to learn about technology or solve problems using technology, it is entirely false. If you want to make a career in technology, it's certainly false: Even old technology needs support, maintenance, and development.

What they might also mean is "X is no longer the only technology that can solve its specific problem", and that's a good thing. Technology evolves when it is exposed to new ideas, and there's no better way to get exposed to new ideas than to compete with other technology. This is why FORTRAN has a new spec coming out, as well as languages like Ada and COBOL.

"X is dead" is anti-marketing. Don't be taken in.

X is Bad

• X is ugly
• X is unmaintainable
• X is terrible
• X considered harmful
• X is bad

Technology is invented at a specific time for a specific purpose. There aren't many technologies that gain widespread acceptance while being unsuitable for their purposes. So, how can that surviving technology be entirely bad?

What they almost always mean is "X is bad to use now", and that's also often false: While there may be more and better solutions to the particular problem (which, as explained above, is a good thing), a surviving technology often still has niches where it fits better than any other. This does mean that you need to do your research: Look at the problem domain, find the solutions, and if you have time, try them out to see which one you like better. Don't let "X is bad" stop you from trying X out to see if it solves your problem.

What they may also mean is "X teaches bad things", which is vehemently false: Learning about the history of a technology is important. Learning about historical problems and solutions is important. Technology is built for a reason. Learning those reasons will explain the design decisions made. Learning about design decisions and tradeoffs can teach you how to proceed when nothing is a good option. No technology is built to be deliberately terrible (though some technologies are certainly satirical or farcical, they are excellent satire/farce and should be evaluated as such, like INTERCAL).

I have, in fact, learned the most from learning other languages designs. Java taught me a lot about OO, which I brought in to all my programs. Using pthreads in C++ taught me a lot about process safety and message-passing, which I then started using Zeromq to solve for me (when I can, but I still know how to solve that problem without if needed). The more shell scripting I learn, the less work I end up having to do (fact). Shell taught me fantastic lessons about composability of programs that I never thought possible, and I’ve got some projects that take full advantage of that.

"X is bad" is almost always a disingenuous attempt to get you to use their favorite technology. Don't be fooled!

Technology is not a popularity contest. Technology is not good because it's popular, and it's not bad because it is unpopular. Technology is not good because its unique, and it's not bad because it exists in a crowded maze of solutions, all alike. We need to evaluate technology objectively and critically, whether popular or unpopular. And we must always remember to be kind to people using technology.

For what seems hours, you scan the board. The colors are sharp against the simple background. Some movement catches your eye, but it doesn't feel right, so you ignore it. Time stretches on.

There! The perfect move. Leaving the perfect next move. A quick flick. A match. The pieces fall into place. Another match. Another. Another. A special piece. Another special piece. It fires, triggering more. Chaos consumes.

The board is in ruins. Your carefully planned next move is lost in the destruction. You're back to scanning the board to try to find where you belong in this new world.

Is this a game, or is it your development strategy?

Software development is chaos. Either you work to managing chaos, consuming it, or it works on consuming you. There are too many possibilities, too much input, to brute-force your way to completion (how much software do you know of that can be considered complete?).

In the face of these possibilities, a rigid development plan will fail. Vague goals are better. Goals written in terms of a problem are best. Problems don't change, once you find their roots.

I didn't know this post was going to be about Agile, but there it is.

Exact is for computers. We are not computers. We are human. We are chaos.

The past me is another person. Sometimes antagonist, sometimes friend, past me (postaction?) had ideas, hopes, and dreams and developed some of them into software that I and others use. Unfortunately, that asshole left bugs all through the code for me to fix.

I can't blame him. Nobody's perfect, not even idealized/demonized copies of my past self. But I do have to fix them, and deal with the messes he left.

Lucky for me, while he was writing buggy software, he left extensive notes for me to use...

Continue reading Leaving Crumb Trails -- Talking to Myself...

My job at Bank of America consists largely of data collection and storage. To collect data in Perl, I have to write XS modules to interface with the vendor-supplied native libraries. Because I want to know my code works, my XS modules come with robust test suites, testing that everything works correctly.

Since the XS module was intended to be used by other, larger systems, I decided to help those larger systems test their dependency on my module: I included a Test::MockObject that mocked my module's interface. By using my test module, the tests can try some data and see if their code works.

But the hardest part to test is always the failures. How do they test if the news service goes down in the middle of a data pull? How about if it goes down between data pulls but still inside the same process? How do they test if the user has input an invalid ID for data?

Continue reading Testing is a Feature of Your Service...

How often have I told myself, "I'll kludge this now and rewrite it later"? And how many times did I actually go back and rewrite that kludgy bit? "Too often" and "not enough". Many job postings include the phrase "update legacy applications," as a euphemism for "rewrite poorly-designed spaghetti." The Y2K problem was a huge exercise in code out-living the developer's plan, with a healthy dose of cargo-culting thrown in. Lately, I've been learning to plan for a likely possibility: My code will survive to haunt my bug lists and my resume for a long time.

Continue reading Chicago.PM - Beyond grep - Expanding the Programmer Toolset...