Programming Sucks! Or At Least, It Ought To

Programming is not fun. It’s boring, it’s tedious, and it’s certainly not challenging. And no matter how much you stretch it, programming is most definitely not sexy.

I know what you’re thinking. Anyone who says that – let alone blogs it – should immediately be stripped of his software development license, have his keyboard taken away, and be permitted to only use only to CP/M on 8" floppies with a 1200 baud modem.

Obviously, a lot of us – me included – enjoy writing code. But should we?

Why do we write code?

Software development is a unique profession in that we can use our skills both on the job and for our hobby. And unlike accountants, who generally don’t rush home to balance the family budget, many of us actually do tinker with code for fun.

But for the sake of this article, let’s only consider the non-hobbyist developer, and the work that he does. In fact, let’s narrow this down even further, and consider only developers of “boring” software. And by “boring”, I mean bills of lading processing, corporate fleet usage tracking, expense report creating, etc., all for internal use with lots and lots of company-specific requirements. So, to reiterate, if you don’t create “boring” software for a living, then this article doesn’t fully apply.

While the line between “boring” and “sexy” software can be blurred at times, sexy software represents the type of things that we use on a regular, day-to-day basis: SVN, Google Maps, Visual Studio, Firefox, etc. In fact, as software developers, we rarely have to use boring software ourselves.

From a development perspective, however, the percentages are flipped. Only a select few get paid to develop “sexy” software, whereas most of us are stuck developing the boring stuff.

Basics of Boring Software

There’s a term for this type of boring software: information systems. And while the purpose of an information system changes from company to company, as do the specific requirements, they all are essentially the same. There’s a database that models the real world, rules to define how the data may be changed, an interface to the database, and lots of different reports.

The formal process of creating these information systems was first created in the sixties and hasn’t changed much since the seventies (Modern Structured Analysis is surprisingly still modern). Essentially, you analyze the problem, map the dataflow, structure the dataflow, create the database, and create programs that interface with the database.

We’ve gone from thin-client green screen terminals to thick-client PC applications. Then we went to the thin-client web and, with platforms like Windows Presentation Foundation, we’ll be back to thick-client in no time. But either way, the systems do all the same thing: data in, data out.

Developing information systems hasn’t changed much, either. Whether you’re using Visual Basic 3.0 or XHTML, the concepts are pretty much the same: the database needs to be exposed to the user in user-friendly terms. The code required to do this is, and always has been, fairly tedious:

That’s five lines of code just to set some UI properties. Multiply that for every field, for every entity, and then by 1.5, just because some fields have to be accessible in two different places. Now add in all the code required to validate and save data from the UI. If my math serves me right, that adds up to a crapton of tedious, boring code.

The Developer’s Dilemma.

“Tedious” and “boring” are two words that don’t sit well with developers. We’re an analytical bunch and oftentimes come with a computer science degree. And we’re much more capable than tying a front-end and a back-end together using line after line of code. Perhaps we could even use our skills and capabilities to make our job easier.

And therein lies the rub. As Michael A. Jackson said in his 1975 Principles of Program Design, “Programmers… often take refuge in an understandable, but disastrous, inclination towards complexity and ingenuity in their work. Forbidden to design anything larger than a program, they respond by making that program intricate enough to challenge their professional skill.”

This thirty-five year-old observation is confirmed day-in and day-out here on TDWTF. Some of the most egregious code and stories written here stem from the developer’s desire for cleverness. Carrying out these desires is neither malicious nor devious, but merely instinctual.

When I wrote about Soft Coding, I presented a snippet of business code to illustrate what the majority of code should look like: i.e., very specific code to implement very specific business requirements. It’s pretty boring:

In the numerous responses to the article, some people offered some rather humorous feedback, demonstrating ways that the code could be “complexified”. These examples were, sadly, fairly representative of what I’ve actually come across in response to simple business requirements.

Others offered some serious refactoring suggestions involving all sorts of design patterns, interfaces, supplementers, and a whole lot of classes. Naturally, all without ever seeing the module that the hypothetical code resided in, let alone a broad understanding of the overall system and its requirements.

And then there was this one guy, James Taylor, who basically called me an idiot for suggesting that developers get their hands dirty with business rules. Apparently, we should all be building whiz-bang expert systems with fancy UIs that let the end user do all of the dirty work.

Of course, those of us ground in reality understand that such expert systems exist only in the land of pixie dust, unicorns, and lossless compression of random data. But there’s another reality that many of us have yet to accept: application development sucks, and no amount of XML or design patterns will change this.

Just Suck It Up.

It’s not easy to reconcile the fact that the software we write each and every day is, for all intents and purposes, mind-numbingly boring. Magazine subscription management. Medical billing reports. Realty inventory management. This is not the type of software that changes the world. In fact, it probably won’t even put a smile on someone’s face. Its sole purpose is to add to the bottom line by making other workers be more productive.

As unexciting as it may be, it’s our job to do work *exclusively* to benefit our employer, not for own personal satisfaction. That’s just what it means to be a professional.

I’m sure that many aspiring lawyers would jump at the chance for an exciting jury trial, but would just as quickly give it up if it was in his client’s best interest to settle. While architects dream of opportunities like Fallingwater, if the design calls for a large warehouse with loading docks, then that’s all the blueprints will reflect. And if our employer needs software to manage voucher payments, then they should get exactly that, not a “plug-in based system with extensible, run-time parsed UI templates,” or whatever else we tricked ourselves in believing was necessary.

Rethinking Software Development.

As frustrating as it can be to work with the uninspired, sloppy developer, the contrary – the inspired-yet-misguided one – is several magnitudes worse. A few bugs and painful-to-maintain code pale in comparison to the disastrous results an improperly motivated developer can deliver.

Everything from the platform (“let’s try out Ruby!”) to the architecture (“can’t just have two tiers”) to the techniques used in the code itself (“we need an aspect-oriented framework”) can be – and often are – influenced more by the desire to learn the technology than to serve the actual business need. Pick the wrong platform or invent the wrong technique, and the project is inevitably doomed.

Having doomed more than one project as a result of my desire to challenge myself, I’ve come to learn that there are some essential rules that must be followed when developing business information systems.

1. Learn the Business. It’s preposterous to believe that you don’t need to understand the business in order to develop software for the business. Without understanding what their actual needs are, it’s impossible to give stakeholders what they actually need. That’s right: when they say they want a “new database for every day”, they don’t actually mean a new database for every day.

2. Serve the Business. Every tradesman wants to use the latest, greatest, and most powerful tools, but rarely are they appropriate for the job. Likewise, there’s hardly ever a business case to immediately upgrade all platforms/libraries/languages. That 10-year old “Classic ASP” code hasn’t gotten worn out, just much less fun to maintain.

3. Learn Off The Job. Self-improvement is a tenet of every profession, but the place to do that is “off the job,” i.e. not while developing information systems1. Instead, learn by creating applications for yourself, your team, or perhaps even some open source project.

4. Code mostly Business. If the overwhelming majority of your hand-written code isn’t domain-specific and doesn’t relate to the application’s purpose, then you’re using the wrong tools. If you truly believe that the system needs a custom logging framework, then externalize it and get a buy-in from the stakeholder.

5. Tedium is Inescapable. No O/R-mapper or code-generator can ever solve the fact that records, fields, validators, etc. need to be defined, by hand, in at least two places (front- and back-end). A UI generated from the database is just as bad as the database that’s generated from the UI.

6. Find Satisfaction Elsewhere. If your only satisfaction comes from writing complex code, then you’ll never be a good and satisfied applications developer. Personally, I’m happy to know that I helped increased productivity for the end-user and/or created new opportunity for the organization.

... and, if all else fails...

7. Get Another Job. Maybe you’ve reached your value apex. Or maybe you’re just sick this type of development altogether. Either way, there are plenty of programming opportunities out there that don’t involve boring, information systems. Of course, the competition is much fiercer since the Paula Bean-types seem to only fly under Corporate IT's radar.

At the end of the day, the best programmers are not the ones who create the most beautifully-elegant, exceedingly-innovative code. The true rockstars can deliver software before deadlines, under budget, and that does exactly what the business needs. And those are the type we should all strive to be.

UPDATE: 1 To clarify, “off the job” does not mean that you should’t learn at work. Learning is important, but don’t do so while developing an information system for the stakeholder (“on the job”). Save that for your own or your team’s internal projects.

[Advertisement]
BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!

Featured Comments

I agree with everything here except that any of it sucks. It is a joy to write clean and well structured software that solves mundane problems. That joy comes from the satisfaction intrinsic in doing a good job. Being professional doesn't suck at all. Being professional is the most fun of all.

Note From Alex: I definitely agree, and hope this setiment came out in the article. I love doing what I do, not because of the "boring" tidbits of code required to do the job, but because of the overall value I can deliver.

If writing software is boring, the problem is not the software. I have written business rule databases, math engines, double-entry bookkeeping systems, GUI frontends to scientific equipment, and the only thing that they all had in common was that I had a great time doing it.

Maybe it's just me, but writing software is about solving problems, and I find that interesting and fun regardless of the application. "Sexy" is in the eye of the beholder. At the end of the day Google Maps is just another map application, the iPhone is just another mobile device, and anything written in Visual Basic is--well, okay, that one's probably not ever sexy.

The section about programmers creating complicated (sorry "elegant") code just to keep them interested in a project reminds me of one of the best lessons I learned in Software U.

It was in the Advanced Fortran class one evening, and our teacher, George, enters the room. His 35 students await the wisdom he has for us. Without saying anything, George turns on the overhead projector and slaps a transparency on it with a code fragment. He asked simply "what does this do?", then waited. Our young minds couldn't quite penetrate this problem, something to do with matrices is about all we could figure out. Finally, George shattered the silence and stated that that routine merely zeroed out a matrix. Nothing more. He then walked us through the code. It was elegant, and beautiful and fast! I glanced around, and noticed everyone else doing the same, smiling and nodding, all thinking "wow, that's really clever!" all hoping they could be as clever as the code's author. After a short pause, George said "I bet you think this was clever code, don't you". The young skulls full of mush nodded in unison and smiled. "You're right, it is clever....it is also bad coding." He went on to explain that while it was clever and fast and efficient, it was also bad code because we couldn't understand it! It would have taken only a few extra lines of code to do a more traditional and slightly slower approach, but it would have been much easier to support. Rare is the routine that really needs to be optimized, he said. "Choose clarity over speed, if speed is not absolutely needed."

So whenever I find myself trying to hand polish a loop and things get more and more complicated (er, "elegant") I think of George's example many years ago and design for readability not cleverness.

5. Tedium is Inescapable. No O/R-mapper or code-generator can ever solve the fact that records, fields, validators, etc. need to be defined, by hand, in at least two places (front- and back-end). A UI generated from the database is just as bad as the database that’s generated from the UI.

And if you have a UI generated from the database, and a database generated from the UI, you end up with Filemaker

So many people here are jumping to the opposite extremes on this article.

I believe that Alex was trying to simply bring to light a famous quote by Albert Einstein. "Make everything as simple as possible, but not simpler."

When given the task of creating a simple application that serves a specific purpose (for example a digital punchcard application to track employees signing in and out) we have the opposite extremes of "lets just make it one big function and store it all in memory because that's the 'simplest' solution" and "lets make a expert system that has the adaptability to cope with almost anything the user can throw at it and then we'll have the user create business rules to make the system behave how they want it"

Anyone with a brain can see that either of these two options are mind numbingly stupid.

The real goal of software design/engineering/programming is to build a system that is "as simple as possible, but not simpler." Start with the basic requirements, build it in such a way that it is easily maintainable, leave the door open for reasonable expansion. ie, in a punchcard ap I shouldn't waste time ensuring that if the customer wants to expand it to an entire store management and accounting system I can easily plug in a module to do that, but it's likely worth my time to consider that perhaps the customer will want to have this application export this time data to a payroll application or might want to run a couple reports off of the time data.

It is perfectly reasonable to have major changes require non-trivial effort. It is also perfectly reasonable to not require recompiling a 20k line program simply because the customer wanted to change the name that appears at the top of their receipts.

The difficult part of programming comes from balancing these two extremes.