Most business logic problems are not inherently complex -- the overwhelming majority of programmers in the world will spend the overwhelming majority of their time on the routine practice of their profession, not pushing its boundaries. Same with doctors or lawyers for that matter.

This categorically does not mean that the routine parts of the job suck. I write CRUD code for Japanese universities. Sample: there is a table which holds session data into it. Take the number of people who are currently logged in and record it to a file every 5 minutes. Make the file accessible by FTP for another system.

Is it going to set the world on fire? No. Is it an opportunity to practice my craft, to carefully design around the obvious issues and the not-so-obvious ones? Yes. Does it improve the lives of my customers? Yes -- that file makes a graph possible and that graph is going to get one forward thinking administrator a raise because it will demonstrate that the project he staked his organizational capital on is a success. As it should be, as the project (which is MUCH bigger than me) helps the university and its students out scads.

It doesn't have to be a multiorgasmic thrillride EVERY day of the week, you know.

The truth of good software development practices is that there are no absolutes. We work in an abstract world, where the architectures we build are limitless and the requirements are rarely complete.

For instance, the author seems to be preaching hard-code business logic rather than dynamic data-driven logic. Well you can't really make that decision in a vacuum. It depends on how often you expect those conditions to change, whether you need to use them in another context, if they are dynamic who will be responsible for editing them, what is the cost of editing them incorrectly, how does the additional dynamic logic dilute the clarity of the program, etc.

In my experience, writing the CRUD code is not tedious. Once I decide what needs to be written I type it out in a couple of minutes (your framework has facilities for this, your IDE has autocomplete, right?). However even the most trivial app is full of critical decisions based on the reality of the business requirements. Every decision is interrelated and has many potential outcomes that are difficult to quantify. What I find fascinating is trying to provide the best solution to a business problem. There's no busywork about it.

Unlike, say, photography. Or cooking. Or music. Or...

He kinda lost me there. You are not a beautiful and unique snowflake.

So, not unique then.

Taking a VERY vague description for a database frontend and fleshing it out into a useful, intuitive, fast website actually IS fun and interesting and non-sucky to me. Seeing a client visibly pleased and impressed with my work is very fulfilling and rewarding. Experimenting with new technologies (in moderation) to accomplish these tasks is fascinating and educational.

Not my experience. Once you frame the question properly, they often know exactly what they want. It's not that they need "search", it's why they need search.

"Oh, you need to be able to determine the top 3 x's whenever y happens so that you can do z."

Fine. Just tell me the "what" and the "why" and I'll figure out the "how".

I understand your pain. Most of my clients skip ahead to the "how" before expressing their implicit "whys" and "whats". It's our job as systems analysts to slow them down and do it right. But then we never did sign up for easy, did we?

Of course, one major constraint in large corporate/government development is not being able to speak directly to the people who will actually be using a system. I've often had the experience of spending months developing and producing a working system before being allowed to show it to any of the eventual users. While incredibly stupid and occasionally frustrating, this can make development much more interesting and challenging.

Not true. Look at systems like Magritte (or my Perl variant, Ernst), for example.

http://www.lukas-renggli.ch/smalltalk/magritte

The idea here is that you define everything once, and then generate the storage and interface layers from that. It's a really good idea.

Code mostly Business

FWIW, ignoring this approach has saved our company hundreds of thousands of dollars. Every minute we "waste" writing reusable libraries ends up saving hours on all of our future projects. And it's fun too.

Who says you can't have fun for the sake of fun?

Too many people are looking for a definitive silver bullet on either edge of the spectrum, but there is none. Every problem will call for a solution that is somewhere in the middle.

People should try more of the first -- there is way too much of the second. If your project is going to fail horribly, at least write some open source libraries. ;)

A library used by zero projects is going to be nearly useless!

http://weblog.raganwald.com/2006/09/business-programming-sim...

Tedium may be inescapable, but defining something multiple times pretty much guarantees that at least one of the defintions will be wrong and usually takes more time than defining said something once.

Normalization isn't just for databases.

Then don't do that.

> I haven't found a good rapid-feedback way

Is rapid more important than correct?

> Do you have any suggestions about what kind of software you use that avoids that?

They're both scriptable.

The Java eco-system evolved to solve some problems that really are hard, not just simple problems. However you are totally right about the complexity - the real issue is that the complexity introduced by the solutions often equalled or surpassed the complexity of the original problems themselves. And even worse, often people didn't need the problems solved in the first place, but Java gave you the complexity anyway.

So, for example, it is nearly as hard or even harder to learn the JEE specs and all the ins and outs of the java app servers that implement them as it is to solve the subset of those problems you care about generically yourself.

The difficulty with automation is that it can take longer than solving the problem by hand. But I'd contend this is a short-term viewpoint. First, very few problems are entirely unique; there's always some general component that they have in common with other problems you may have, even if that general component is not immediately obvious. Automating a system now almost always means less work in future.

Second, at least in my experience, a programmer would much rather write a program to do something boring than do it him or herself. Automating a repetitive task is immensely satisfying, especially if it continues to save time again in future. If you work for a company that encourages programmers to automate everything, you're probably a lot more motivated than a programmer that has to do something excruciatingly repetitive, and a lot less likely to be checking recruitment agencies.

When I starting working for my current employer, a lot of things were hastily done and there was a lot of repetition. Over time, we've snuck in hours here and there to improve our processes. Not as much as I'd like, but enough that we've slowly made progress, and each time we've automated something it's been an interesting and rewarding task. After suffering through manually doing X for the last N weeks, it's very satisfying to ensure you never ever have to do that again.

The rest of the time I love every minute of it and I'm enormously grateful to have the privilege of being able to spend every day doing it.

It is of course possible to write interesting software in boring domains, make beautiful portraits of ugly people, joke about serious matters, write poems using swear words or intelligent plays with stupid characters.

And on occasion -- if you stay alert -- you can find interesting & challenging small projects that improve the business or make life easier for other developers. Sometimes that might just be a shell script or something. Small victories, I suppose...

Best is to recognize what you love doing, then do that systematically and effectively. But don't turn preferences into rules.

And it is relevant to concentrate on the boring side of software because, as he also points out: "Only a select few get paid to develop 'sexy' software, whereas most of us are stuck developing the boring stuff." It is not trivial to "pick up computer vision", much less get a job in it.

For instance, document management is not very sexy software, but Zed Shaw's recent talk on rethinking ACLs was extremely interesting. I'd love to be able to apply my current language of choice (Clojure) to document management, or indeed any type of software that is usually considered dull.

The boring part of software development comes when, IMO, you don't automate something, or are forbidden to, due to time constraints.

But perhaps that's because I have yet to encounter a truly boring type of software project :)

The article points out that programmers instinctively look for ways to make their jobs more interesting, and that many of these approaches end with solutions that are unusable or unmaintainable. There may well be no interesting and effective way to specify that Arizona and Texas need documents SR008-04X and SR008-04XI.

I don't think developers look for a way to make a project "interesting" just for kicks. At least in my experience, there is a genuine desire to improve the process, to automate everything that can be automated, to invent and create something that's much better than the original.

And sure, they might not get it right on the first attempt, but that's why you attempt to fail early. There is this odd notion that code is sacrosanct; that once created, it must never be discarded, that we should never change our initial ideas, no matter how wrong they may be. I'm of the opinion that this is not a good way to solve a problem. If you're heading in the wrong direction, then you turn around. You don't keep driving, hoping for the best, yet this is exactly what most software projects seem to do, and why they ultimately end up in disaster.

The ingenuity of the developers is not necessarily at fault; rather its that they or their managers are afraid to fail early, so they fail when it's too late. We shouldn't shy away from ingenious solutions because of this. The corporate world is too short of ingenuity as it is, and no more so than in the field of software development.

The older you grow, the more important number 3 becomes. At least that has been my experience.

Have you never heard of SAP?

1. You must build a convincing prototype before you run out of Ramen 2. People must actually like using it.

Go!

For medium-size business its much cheaper to hire some pros who will make analysis of your business processes and build something based on modern technologies. The distributed computing is already mainstream with several OSS codebases.

Of course, if you're Boieng or Citi Group there are no alternatives.

And of course it is an ecosystem, where you must pay for every little step. It is much worse than MS.

    # [`supplemental_documents` probably isn’t the only business rule
    # that depends on whether something is a corporation or not, so
    # I’m factoring that out here to make the code more readable than
    # it was in the DailyWTF exercise. -kjs]
    def is_corporation(self):
        return self.orgStatusCode == 'CORP'

    def supplemental_documents(self):
        """Yield the form numbers of the supplemental docs §801.33 requires.

        The NNDDA imposes some special legal requirements because we
        are not a DDTL under §701.2.

        """

        # §801.33(b)(2)(ii)
        if self.stateCode in ('AZ', 'TX'):
            yield 'SR008-04X'
            yield 'SR008-04XI'

        # §801.33(b)(4) (as amended 1998)
        if self.ledgerAmount >= 500000:
            yield 'AUTHDLG-1A'

        # §801.33(b)(8)(i)
        if self.coInsuredCount >= 5 and not self.is_corporation():
            yield 'AUTHCNS-1A'

    def attach_supplemental_documents(self):
        """Attach supplemental docs a customer filing requires under §801.33."
        for doc in self.supplemental_documents():
            self.attachDocument(doc)

Really I think that if your notation for these business rules imposes much more overhead than this, it will be easy to overlook ways that they don't say what they're supposed to say. You don't need to have reams of repetitive, highly-compressible code just because you're doing business applications.

The DailyWTF author scoffs at the idea that "end-users" should write business logic, somehow confusing business-logic DSLs with expert systems. I think that at the very least, you should write your rules in a notation that enables the end-users to understand what they say. I don't think it's at all unreasonable to build a business-logic DSL for things like this, but in this case I think Python might work just as well.

(In fact, the DailyWTF author seems to assert that writing a DSL parser is of equivalent difficulty to compressing random data. For what it's worth, a parser is a lot easier to build than an expert system, but I got news for you, Alex. There are actually working expert systems in the field, there have been for nearly 30 years, and people are building more of them all the time. They don't require any pixie dust or unicorns.)

The "young hotshot" sense of entitlement is pretty repulsive, but so is the "fuck you, I'm your boss" attitude exemplified by the OP. The saving grace of the former is that it tends to fade after an ass-kicking or two.

Some general observations:

1. There's a difference between mundane and boring. Things that are mundane are not thrilling, but rather neutral in their psychological effect. Stopping at a red light is mundane. That which is boring is psychologically offensive. Mundaneness is fine (and inevitable) in software development. Boredom is different. Having a programmer spend 8 hours per day working on tax forms/compliance work, without the option of automating it, is just ridiculous. It actually is better to let him write an abstract system so that someone else's time-- preferably someone less expensive-- can be put to the "dirty work" using his tool.

2. The "big picture" of a project is what makes it interesting and provides motivation; the details of even the coolest projects are mundane. I'd even go so far as to say that 75% of the time spent on a cool project is still involved with mundane details. People unable to handle this fact generally don't become good programmers-- or good anything. What this means is that if someone's a decent programmer, his problem is not that he's unable or unwilling to do detailed work. Even on cool projects, programming is one of the most detail-oriented jobs there is.

3. Mundaneness escalates into boredom only when there are so many mundane details as to occlude the interesting part of the problem... or when no such interesting part exists (e.g. implementing compliance/tax logic). The pattern-match for the supplemental forms is a trivial example of a mundane detail, and certainly not enough to make a whole project "boring"... but 10000 lines of such code is going to become an incomprehensible mess (much like, well, the bulk of bureaucratic red-tape that exists in the business/legal world).

4. Taking a design perspective on this issue, boring things generally belong in data, not code. On the example of the supplemental forms, those rules should be encoded in such a way they can be put into a database. Computers are great for managing large masses of boring information. Humans are not.

5. At root, the OP sounds like he's whining about the fact that he's unable to motivate his employees and that his attitude (which, of course, is without flaws) turns them off.

Just try to write a little article or an essay, leave alone a business plan.

It is impossible to draw a big picture from left-up corner, as matrix printer does.