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:

txtFirstName.DisplayWidth = 30;
txtFirstName.MaxCharLength = 50;
SetTextBoxValidator(txtFirstName, Validations.LettersOnly);
txtFirstName.Enabled = securityContext.CanEdit;
txtFirstName.Value = customerRecord.FirstName;

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:

private void attachSupplementalDocuments()
{
  if (stateCode == "AZ" || stateCode == "TX") {
    //SR008-04X/I are always required in these states
    attachDocument("SR008-04X");
    attachDocument("SR008-04XI");
  }

  if (ledgerAmnt >= 500000) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
  }

  if (coInsuredCount >= 5  && orgStatusCode != "CORP") {
    //Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A
    attachDocument("AUTHCNS-1A");
  }
}

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!