Software Success (an essay on true love)

…and how to get the love back.

Over the last 12 years I’ve worked with a lot of software developers that would fit this description. Totally bored with their job and willing only to do the bare minimum: just enough to get by.

I think I know the explanation for most of these cases, if not all. They don’t love what they do. I got into programming because I loved doing it. After I wrote my first computer program, in QBasic over 15 years ago, I was thrilled that I could control what my computer did. I felt empowered, partially because I found myself capable of doing something that previously seemed beyond my grasp, but also because I saw the possibilities: given enough time it would be conceivable to do practically anything! The first thing I did was write a program to help my teacher parents record grades. A few years later I wrote a WYSIWYG editor in Borland Delphi for creating JAVA user interfaces, which helped me get my first job. This stuff was fun!

But that was 15 years ago.

What about today, when LEGO is selling programmable robot toys! And Microsoft has an entire framework for interfacing with robots and other electronic devices. Given enough time, it’s conceivable to build practically anything! How can you not love this wonderful craft? There’s always something new to build, a new problem to solve, a new way to impress your family and friends and be called “that super geeky whiz kid” for the thousandth time.

I believe this is a craft that must be loved before it can be done well. If you love what you do, you’ll try to do it better this time than you did last time, every time (and you can quote me on that). A developer that throws himself into his craft will probably know about design patterns and whether a Hash Table is better than a Linked List in this particular scenario, or whether this database query result needs to be cached, and on and on.

Joel Spoelsky’s 5-step list to software failure unfortunately (but I think correctly) lists bad programmers as the number one reason for software project failure. I totally agree. But I think we could expand on that a tad, by saying software developers that don’t love what they’re doing, that aren’t motivated by an insatiable desire to solve problems, or that don’t care anymore, are the number one reason for project failure.

Because if you love software development, you will be a good software developer. And if you don’t love software development, you can still fall back in love. Yes my friend, there’s still hope. Read some blogs, buy some books, but most of all (I think), start an interesting side project that you can do at home for a few hours a week that will bring the love back.

Here are some “feel the love” suggestions:

• Build a robotic CD burner using LEGO Mindstorms that will pick up a CD from a stack of CDs and insert it into a CD burner. Program it to burn copies of various CDs stored in a database (or whatever).
• Write a home document management system application that will scan, OCR, and store in a searchable format all of your personal documents, like Mortgage, Tax, and other stuff. How cool would it be if you could search your computer for that stuff instead of having to root through a file cabinet?
• Grab a 15-inch LCD touch-screen, an old (or cheap) Windows XP PC, and hook it up to some of those X10 home automation components. Build a spiffy looking user interface for automating your home, and hang it on a wall somewhere for walk-up convenience.
• Write an application for a friend or family member. Maybe your church or other organization needs an application to send emails, parse data from files, or whatever. Who knows – if you do something well for someone else, it could lead to other, perhaps paid opportunities.
• Teach your kid how to program. My 7 year-old son just wrote his first “Hello World” QBasic application, and I was so proud. Passing on the joy of watching something you made just work is a great way to bring some of the fun back into programming.

If you’ve lost the love, get up and do something about it. It’ll make you a better programmer.

Code Toaster 0.8 Released

There are still a few outstanding bugs, but since this release is infinitely more stable and usable than previous versions, I decided to go ahead and release it as is (and also since interest in Code Toaster seems to be picking up lately).

I plan to release an update in a few weeks with more improvements, as well as bevy of useful template projects and hopefully some video tutorials.

Be forewarned, there is a learning curve, but so far everyone that has climbed the mountain has fallen in love with what this little tool can do.

Please leave any feedback as a comment, or feel free to email me at rmblack at gmail.

Buggy Software

Jeff Atwood makes an interesting point over at his Coding Horror blog, that often times features are more important (from a financial standpoint) than fixing bugs. That people are more willing to pay for an impressive feature matrix than a laundry list of bug fixes that may or may not directly impact their work.

I agree.

In fact, in some cases not fixing bugs can play a bug part in the overall financial strategy. For example, I used to work at a software company (which shall remain nameless) which happened to have a monopoly in their market. There was literally nowhere else to buy similar software. Their software was horribly buggy, and so they encouraged customers to purchase a rather highly priced support contract entitling them to, more or less, call support.

In their defense, I don’t think this strategy was intentional – it was an (un?)fortunate side effect of what Jeff blogged about – to sell a product, new features are often more important than bug fixes. And boy did they have an impressive feature matrix. It was ginormous. Anyone comparing products would be silly to even consider a product with a lesser feature matrix, despite the fact that you might be able to save your data without risk of the application blowing up in your face.

I disagree.

On the other hand, in some cases, particularly for small startups, lots of bugs can mean instant death. I later worked as the Webmaster (back when it was still cool to be a Webmaster) for a popular web-based practice test provider. The entire staff was comprised of about 10 people, most of whom authored practice tests. The development staff consisted of me, my boss, and a contractor in another state that would occasionally do new development. With thousands of people using our site every hour, we didn’t have the resources to field calls about usability  or technical issues. The site had to always work – or else.

Balance and Counterbalance

Fixing a bug vs. just leaving it to fester has to be weighed against the time it will take, and the expected benefit(s), among other things. For example, when working in IT, we come across the occasional bizarre problem that only happens when a particular user right-clicks on a Tuesday under a full moon while winking her left eye. We could spend a week setting up a virtual environment and tinkering with different combinations of environment variables, installing and uninstalling different combinations of applications that may be the culprit, but is it really worth the time involved? Is the benefit there?

That depends too – if I worked for a hospital and the software in question monitored respiration or some such, it would most probably be worth the effort and time. But if it’s a Word template malfunctioning, let’s just reimage the user’s machine and move along.

The Feature Matrix

So, I think ultimately the feature matrix counts only towards influencing the initial purchase. If you have an impressive feature matrix but lots of bugs (like that company I used to work for), you can bet lots of users will start to think strongly about migrating to another product as soon as possible. And they’ll probably tell their friends not to even consider your product. And you’ll have a hard time getting positive product testimonies to plaster all over your web site.

Unless, that is, there isn’t another product for them to go to. In which case, you’re home free you nasty scoundrel, and you should offer a hefty support contract and start raking in the dough.

Funky Design

I was just browsing the web sites of a few design firms we’ve hired in the past, and was quite surprised at how bad this one is. That web site looks like Cousin Junie wanted to give “this HTML thing” a try.

This one here, on the other hand, seems a lot more “safe”. They probably won’t give me a site design that employes creative use of cockroach antennae, or weird swirly black and white backgrounds.

Oddly, the former (weird site) would probably be considered the “better” of the two firms. More creative, with more high profile clients. And a weirder web site.

Go figure.

Code Toaster 0.8 in Beta

The next minor release of Code Toaster, which I’m calling version 0.8, is being tested vigorously by myself and a cadre of enthusiastic code generators. We’ve discovered it works well until you point the included schema provider for SQL Server at a SQL Server 2005 database. SQL Server 2005’s “new” schema ownership model (where objects are owned by schemas, instead of users) is confusing the tarnation out of the schema provider. A fix is in the works.

Actually, previous releases of Code Toaster probably should have been dubbed alpha releases, because they only worked for my needs (i.e. while running within VS.Net), and were only barely ready for public release (including the version {0.50} currently available for download from my downloads page).

This next version will contain numerous bug fixes and enhancements, most notably:

• Enhanced Intellisense support, including member documentation (if available)
• Enhanced error tracking (squiggly lines under errors in code)
• Automatic template output language detection and coloring. For example, if your template generates SQL code, Code Toaster will detect that and color the output for the SQL language. Automatic language selection is only available for a few common languages, however you will be able to manually select from 13 different languages, including PERL, PHP, Phyton, SQL, C#, and more.

Also to be included in the next release will be a very simple Data Access Layer project, called SimpleDAL, which will generate lightweight and (hopefully) easy to understand code for accessing data. I’m calling it SimpleDAL after looking at several other DAL generators which seem to do everything but calculate the earth’s orbit speed around the sun.

And it’s free… like the wind.