Programming Sucks Or At Least, It Ought To

http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-.aspx

by imgabe • 17 years ago

49 40 17 years ago

thedailywtf.com

gaius• 17 years ago

Software development is a unique profession in that we can use our skills both on the job and for our hobby.

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

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

sosuke• 17 years ago

We aren't unique by far but to say that you can easily make photography or music a career is a stretch. Not everyone with a camera and a passion can make a living taking pictures. It seems far more common that those who love to code can get full time employment doing just that. You can also say that photography and cooking are unique in the same way as programming in that it is possible to use your skills on the job and in your hobby. There is no absolute truth in opinion pieces like this but don't discount the whole story on this one line.

marbletiles• 17 years ago

unique in the same way

So, not unique then.

andr• 17 years ago

I strongly disagree. That's like saying we should keep shovelling by hand and not waste time to invent the backhoe. Programming exists to automate tasks and thus lends itself to automation quite nicely. If you put together 10000 code snippets like the one in the article you'll get a completely unmaintainable piece of software. The cleverness the author shuns helps make very large projects possible, among other things.

imgabe• 17 years ago

Sometimes though, you only need to dig a small hole and a backhoe will not only cost too much, but destroy your yard. The invention of the backhoe hasn't made shovels obsolete.

raganwald2• 17 years ago

I disagree as well:

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

msluyter• 17 years ago

It sucks sometimes, imho. I think there's a middle ground between the situation he describes and being on the bleeding edge. Much of my work is as tedious as he describes, but I also get a certain satisfaction out of refactoring legacy code and improving it.

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...

schtog• 17 years ago

Such a bad article.

Some programming tasks are boring, yes(no shit...).

All? No. Programming can be very challenging, obviously it depends on the task.

If you want a challenge I suggest you pick up computer vision, still 20-30 years down the line a largely unsolved problem. Or create tools to make games programming more productive. Or...the list goes on.

jcl2• 17 years ago

He never said "all". In fact, he specifically says: "If you don’t create 'boring' software for a living, then this article doesn’t fully apply."

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.

weavejester3• 17 years ago

I'm not sure there is such thing as an inherently boring software project. You can approach it in a boring way, but given free reign, I daresay a programmer could find something interesting in any project.

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 :)

EliAndrewC2• 17 years ago

The most interesting and difficult part about business programming is that your clients rarely have a good idea what they want. They say they want searching, but what searches will they commonly want to perform? What type of data are they looking for on a daily basis and is there some kind of daily report they didn't think of which would be useful to them? They claim that such and such will never ever change ever, but what happens when it does, and how can our system adapt to that?

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.

edw519• 17 years ago

...your clients rarely have a good idea what they want...

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?

EliAndrewC2• 17 years ago

That's definitely a good distinction; that clients CAN tell you what they need by if you ask the right questions.

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.

patio11• 17 years ago

You should not introduce complexity into software for the sake of adding complexity. That goes without saying.

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.

dasil003• 17 years ago

It's actually pretty insulting that the author assumes most developers are just looking to add needless complexity. The OA is just a multi-page rant against this blatantly braindead straw man.

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.

nazgulnarsil• 17 years ago

But it isn't always adding complexity for the sake of complexity. sometimes it is efficiency in a scenario where making the code 10% more efficient isn't really worth it because it makes the code harder to maintain.

jrockway2• 17 years ago

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.

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?

nihilocrat• 17 years ago

There are plenty of examples of programmers writing systems that are too grandiose to solve simple problems, as well as programmers writing systems that are hacky and not reusable enough.

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.

jrockway2• 17 years ago

There are plenty of examples of programmers writing systems that are too grandiose to solve simple problems, as well as programmers writing systems that are hacky and not reusable enough.

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. ;)

weavejester3• 17 years ago

To me, boring programming implies having to perform a repetitive task that requires little mental effort. I don't think I've ever come across a programming problem that was both dull and not potentially automatable.

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.

boredguy8• 17 years ago

It's funny when people try to universalize preferences. Obviously: don't write bad code. But if you're a maintainer, go about maintaining, don't try and turn everyone into a maintainer. Similarly, if you're a creator, don't try and turn maintainers into something else.

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

anamax2• 17 years ago

> 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.

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.

kragen3• 17 years ago

I basically agree, but there's a certain amount of sense in the statement you're debating — if I design either the database or the UI and then make the other one just a thin layer over it, I get a terrible database design or a terrible UI design. I haven't found a good rapid-feedback way to design them both in a single representation, and so I end up editing code in at least two places when I want to add a field. Do you have any suggestions about what kind of software you use that avoids that?

anamax2• 17 years ago

> I basically agree, but there's a certain amount of sense in the statement you're debating — if I design either the database or the UI and then make the other one just a thin layer over it, I get a terrible database design or a terrible UI design.

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.

time_management• 17 years ago

I'm more offended by the guy's attitude than what he has to say. He sounds like some middle-aged manager who got miffed by some young "rockstar" (ugh, hate that word) and the kid's sense of entitlement... because it clashed with his own.

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.

akeefer• 17 years ago

Most of the Java "enterprise" ecosystem is the result of people trying to make simple problems more interesting by framework-ifying them to the point that they become hard. Not coincidentally, most of the Java ecosystem is also used by/built by corporate IT developers . . .

zmimon2• 17 years ago

I think you are half right but you are a little harsh.

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.

zmimon2• 17 years ago

The only thing I ever dislike about programming is being forced to do it at a substandard level, usually because I have to work with substandard legacy code that is too hard to modify other than by continuing whatever bad practices it employed in the first place.

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.

c00p3r3• 17 years ago

This is a cry of a coder. Monkey coding without an idea and model and plan is hard, for sure.

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.

kragen3• 17 years ago

I actually think you can do a lot better than the code he posted, for the problem he posed. The business logic there is not explained, and drowns in a sea of repetitive method names and excessive punctuation. Here's a version of the code that includes a lot less "noise" and includes references to the applicable regulations and regulatory agencies, which I made up for the purpose of this exercise. I've also removed the original comments, because they simply restated verbatim what the code said, as a sort of acknowledgment that the code wasn't as readable as it should be (although I didn't think it was so bad as to require comments).

    # [`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)

I don't think the "self." is an improvement here, but despite that, I think the code that actually contains the business logic is a lot more readable this way.

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.)

zupatol• 17 years ago

To some extent, he confuses the beauty of the problem with the beauty of the solution.

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.

Programming Sucks Or At Least, It Ought To

Related Stories