Time for Song

Hacking and methodologies and pointy-haired-manager busting and SQL and language wars and best practices and requirements gathering and testing and bugs and dealing with spaghetti code and arbitrary deadlines and corporate America and viruses and still trying to fit time in for family and gaming and reading. Whew.

Take a break and enjoy a song from eccentric folk singer Johnathan Coulton. This one's called Code Monkey and it's hilarious. That it works on several levels (poking fun at programmers and their struggles with management, social ineptness, and dreams of success) might be genius, or it might be serendipity.

Either way, the song is catchy and this page includes a link to the song, Coulton's song notes, and feedback from several listeners. Elsewhere on his site you can also find the lyrics. The only thing I would have changed is the song's reference to "Tab and Mountain Dew." In my universe, it would be "Code Red Mountain Dew."

Define Happiness

If someone came to you and asked, "Are you happy with your IT job," how would you respond?

Obviously, the person asking would have an impact. You might answer differently if a friend asked than you would if a manager asked.

At the risk of sounding Clintonesque, I think you also have to clarify the question first, by saying, "Define happiness."

If you spend time reading the mentally engaging discussions at Joel Spolsky's site Joel on Software, you might get the impression that the ace developers out there all want jobs where there's no overtime and a working environment void of interruptions. Both of those are good things to have, and both are the sorts of things the evolved software development experts talk about (guys like DeMarco and Lister).

The truth is that it's considerably more complicated than that. There are varying types of developers and varying types of IT jobs. So, as is often the case, before we can answer the original question, we have to answer several other questions.

I'll be exploring this before returning to the happiness question.

Software is hard

My motto for a lot of this blog is,

"Making software is easy, making it right is hard."

Well, I was certain others had thought of that sentiment before me, and now I have proof. Donald Knuth had this to say in a lecture, captured in a document of the American Mathematical Society.

...my main conclusion after spending ten years of my life working on the TEX project is that software is hard. It’s harder than anything else I’ve ever had to do.

There you have it. Don't take my word for it, listen to the college professor.

Thanks to the gang at Joel Reddit for linking to the article. If you want to learn about the world of software, spend some time at this Reddit site. Great stuff.

Happy New Year (plus nerdiness)

Here's a post to prove I'm a nerd. If you haven't seen Firefly or Serenity yet, and you're an SF fan that got tired of the Star Trek formula, you might want to give it a shot. Then the rest of this post will make some sense.

-----

Your results:
You are Malcolm Reynolds (Captain)

Malcolm Reynolds (Captain) 70% Zoe Washburne (Second-in-command) 65% Wash (Ship Pilot) 65% Kaylee Frye (Ship Mechanic) 65% Dr. Simon Tam (Ship Medic) 55% Derrial Book (Shepherd) 40% Alliance 40% Inara Serra (Companion) 35% Jayne Cobb (Mercenary) 30% River (Stowaway) 20% A Reaver (Cannibal) 10%

Honest and a defender of the innocent. You sometimes make mistakes in judgment but you are generally good and would protect your crew from harm.

Click here to take the "Which Serenity character are you?" quiz...

More to come

I haven't been posting lately...getting settled into lots of new things. Had a job change just before the last post, and also on a bit of a different schedule now. But don't worry. I'm hardly out of ideas and rants.

Anyone can become a Developer; the Trick is staying a Developer

At the risk of alienating some of the readers, I will tell you about my favorite writer. It's this angry guy named Harlan Ellison. He's quite famous in the fiction circles, though it was his non-fiction that really won me. He has a cynical streak and is very intolerant of the incompetent. It's pretty refreshing stuff to read as you journey through this life and become frustrated with the reality that in the US, society not only tolerates mediocrity and incompetence, but encourages it.

I had the honor of hearing him speak at some of his public appearances. One of the things he said really stuck with me.

Anyone can become a writer. The trick is staying a writer.

I think that's a fascinating statement. To me, it means that each person knows at least one story that he or she can tell better than everyone else. But it also means that the art and profession of writing is something that requires more than the ability to communicate. It also requires some measure of passion to do well. There's another profession like that: software developer.

In an earlier post, I said that anyone could become a developer. Well, that's true, but I also said this:

Making software is easy, making it right is hard.

To really be outstanding at making something as complex as software, you need to have a true drive for learning and improvement. That means more than 40 hours/week of effort. That means taking time to read other blogs and books, and to take classes, even if the IT department you work in has cheap-ass management that doesn't understand that the best IT staff is one that's educated and skilled. That means paying for it yourself if you have to or finding work somewhere where the management values employee development.

This is especially true in an industry like IT, where the technologies can change in the space of a few years. When I first went to EDS, I learned COBOL. I didn't care for it, but it put food on the table. I always yearned to work on PC-based tools, and eventually got to a project where I learned PowerBuilder. But at this early stage, I was still struggling with learning so many things. I was still learning about my client's business, about event-driven programming, and about SQL, and I was clueless about Object Orientation. Frankly, I was not very good then, and my stuff sucked.

With time, I figured out the tool and now consider PowerBuilder to be one of the best development tools ever made. If you need to connect to and do work with an enterprise database (or even a less-than enterprise database) and you are not using the PowerBuilder datawindow, you are spending more money, time, and effort than you need to be.

So why did PowerBuilder (PB) lose it's luster in the market? A big part of that is the way Sybase handled the product after buying PowerSoft. But it didn't hurt that most developers are idiots. They are so into chasing after The Next Big Thing(TM) that they never stay with a language long enough to develop a level of mastery. I've seen a bunch of PB code over the years and most of it was mediocre at best. There are guys that have been using it for years that never truly utilized the power of the tool. It supported the big three of OO (encapsulation, inheritance, and polymorphism) long before Java ever existed! But guess how many of the PB apps that I've seen actually used OO? None, but in all fairness I didn't really understand it until I took a Steve Benfield class back in 1997. That is really sad, that most developers don't really use the power of OO (or PB), but a deeper discussion of that is for another day. To me, understanding OO is what truly separates the mediocre developers from those that finally hear the music and take that step towards advanced developer. Maybe I'm wrong, but the body of code I've seen indicates that many haven't made that leap.

Getting back to my point, one of the pivotal parts of staying a developer is to grow your knowledge. Besides commitment, patience is a big part of that. Experience counts for a lot in making software, because the core challenges in this industry aren't likely to change. Oh, the intensity and the trappings of the challenges can rise and fall with the changing times, but things like data access, data storage, security, concurrency, and performance will always be the things we struggle with, and the mediocre will fail to consider, happy as they are to simply toss out a huge nesting of IF statements. Striving for adaptability, agility, maintainability, and elegance are the things to which the mediocre will only be able to give lip service. I can't tell you the number of times I've seen complicated spaghetti code, and thought how it would be so much easier if the folks that built the app would have used true OO. OO is a bit tricky to figure out at first, but once you get there, you realize it's the only way to make code more agile.

Even after all the years of learning, I still consider myself far from where I'd like to be. But I see definite growth in my knowledge. And I did it mostly by focusing on one language. Thankfully, it was PB, and not something like a pre-.NET incarnation of Visual Basic. I was able to overcome the initial learning curve, which included the crucial step of making mistakes and learning from them, then continued to simultaneously grow my understanding of the advanced capabilities of the language while reading about programming theory in general. Little of this actually happened while scrambling to meet deadlines...most of it took place after-hours, reading technical journals or in specific technical classes.

That's why it kills me when companies get upset about the poor quality of software, but are at the same time throwing poorly managed software projects at their developers and refusing to pay the cost of employee development. If corporations don't want to invest in sending their janitors to advanced skills training, that's one thing, but if they don't send their thinkers to learn the new tricks in an industry where things are always changing, they're only hurting themselves. Still, if you're not one of the lucky ones working at Computerworld's Top 100 Companies to Work for in IT, then you're often like me, forced to figure out this stuff on your own.

That's why staying a developer is tough. It takes work to improve yourself. There are ways you can get away without putting in the extra effort, and there are also things that can compromise your efforts even if you do make them. More on that in a future rant. But if you're serious about staying in IT, at some point you're going to have to learn something either because you want to or because the environment forces you to. But don't always assume the learning has to be in a new language. If you're using the right language (something that supports OO like C, PB, Java, C#, or VB .NET), you'll be able to make dramatic improvements in your ability by studying advanced techniques and applying them right where you are.

This is where chasing The Next Big Thing can be wrong. I think that getting over the newness of a language is a critical part of being able to move on to using it with advanced concepts. If you don't get to the point where the syntax becomes second nature, then you'll always be in cut-and-paste mode, the thing that might be the biggest cause of PB's demise. Cut-and-paste is a symptom of procedural logic, and procedural logic is the mental baby food of poor or mediocre developers. I can guarantee you there are still people slapping procedural logic routines into their Java and .NET objects and then patting themselves on the back and saying, "Look! I did OO programming!" No, that's "Uh oh programming." The people that never figured out OO while learning PB took their same bad habits to Java, then to .NET, all in their pursuit of The Next Big Thing. The Next Big Thing can't materialize because it's always being compromised by The Worst Old Thing.

Don't be fooled by the few in this industry that write the magazine editorials and work in ivory towers where they get to play with whatever they want and don't have deadlines. They write about how your programming tool is dead and you are crap if you don't move to The Next Big Thing. I say to them, "You're lucky, good for you, now shut the hell up, not all jobs are like yours. The rest of us don't want to hear about your time at the tech conference in Hawaii. We have to figure out how to resolve problems in a myriad of apps supporting a multibillion dollar company, and no, the app isn't written in the latest and greatest, but it's putting food on my table. Who's going to do that if I take a few years off to study an obscure API in .NET? You?" Staying a developer requires learning, but learning isn't always about a new language, sometimes it's about making better what you have, and it should be more about improving productivity than improving resumes.

Once you've achieved proficiency with a language, and are confident that you understand OO and have migrated from cut-and-paste to model-design-and-iterate, then you're probably at the point where you can start picking up all kinds of newer languages because at least some of the universally useful concepts are understood and can be translated over. Sometimes, if you know what you're doing, you can appreciate when the new thing, say Java or .NET, can offer you something your old language didn't like implementation of operational polymorphism through things like interfaces. But I'll bet a lot of the ex-PB guys that went to Java and .NET first heard about interfaces and said, "Huh?" And if you've used interfaces for a while, you know they are powerful, but like recursion, can get confusing if you don't design them well and apply them judiciously. Guess who probably implemented hundreds of interfaces without thinking first?

Anyone can become a developer. But if you want to stay one, try climbing to the next level before moving to the next language. Try supporting your own crappy code for a while, feel the pain those that support and use your apps feel, learn from your mistakes, and realize that there are better ways of doing what you think you're so good at. If you don't, you'll be dumping more of your crap on the ones that follow, you'll just be doing it in a different language. You can count on the lack of metrics in our industry to shield you for a while, but sooner or later, the smart ones are going to stop hiring you.

Recent Outsourcing Horror Visions

I'm hardly the first person to gripe about this, but there's an unsettling trend in America to send work offshore. The proponents of this practice defend it by saying that manufacturing and industrial jobs also went overseas but didn't compromise American supremacy.

Well, they're half right. There are some responses to this trend in the July 2005 Software Development magazine's feedback section (registration required). Michael Wheelen's letter succinctly identifies the entrapment of the American IT worker. An excerpt:

"We as American workers are stuck. Until cost and pricing stabilize around the globe, our economy will suffer the most because we have the highest cost of living."

And:

"The global economy is here to stay, but let's replace the old dogs with young dogs - people who understand the new technology and can manage it to everyone's benefit; young blood can create a win-win for corporate America and the public. For example, why not let the corporations outsource, but when the end product returns to America, fix the profit to a certain percentage of cost?"

Great letter, but of course what Wheelen is asking for isn't going to happen. In particular, with software, there's no tangible product to tie a profit to, and as IT veterans know, no software truly has a finite cost - as long as it's alive and being used and maintained, the true total cost grows with the life of the software. The old dogs have a little too much power too, and it always seems the young dogs that finally do replace them have learned their tricks from the ones that went before.

In the same issue, another letter, American Decline, from Thomas Ronayne serves a chilling image. He wrote:

"American companies are run by fools interested only in short-term results, and the offshore community is ready, eager and willing to
step in and take over. Because the relationship between government and industry in the United States is adversarial (compared with that in, say, Japan and Korea), we've seen the steel industry more or less vanish, the automobile industry get into deep trouble and the electronics industry disappear...we're on the rapid road to becoming a client of other countries that are willing to invest in their future. If we had to fight a war with Asia, we wouldn't be able to produce the basic materials we'd need to do so."

I hope that's a touch more sensationalist than reality would have. I'd read not long ago about how the steel industry in Philadelphia is making a bit of a comeback because after demand outpaced supply in other countries, the US was able to compensate at a competitive rate. Economic equilibrium is the key to making globalization less painful. Still, I can see the US being stupid enough to get to a point someday where the native industrial capacity could be completely gone, or enough diminished that if a wily agent of chaos could organize our allies to turn on us, there would be no foundation to support a future generation's "Rosie the Riveter."

But in the previous generations of offshoring, and in Ronayne's vision, the jobs being sent away from North American borders were largely physical jobs not involving soft skills. And if you look at the industrial offshoring efforts, not all of the work even left North American borders, moving to Mexico and Canada (ah, how arrogant we are to assume that America or North America always means "the USA").

But the know-how is still in the US! If there were a disaster, or a war with large scale scope, I'm optimistic that our engineers and surveyors and construction workers could find a way to adjust and still get the work we needed done at home to support a war effort. And North America is still a gifted geographical wonder, with natural resources galore, and still bordered by large bodies of water. You can compromise your opponent's industrial capacity and maybe even its economy, but no one gets a free pass from Mother Nature. Invading the US wouldn't be the cakewalk that Ronayne thinks it would be.