
Programming Sucks Or At Least, It Ought To - imgabe
http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-.aspx
======
patio11
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
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
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.

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

~~~
bonaldi
_unique in the same way_

So, not unique then.

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

------
EliAndrewC
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
_...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?

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

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

~~~
jrockway
_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. ;)

~~~
blasdel
A library used by only one project has a pretty high barrier to use.

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

------
raganwald
I disagree as well:

[http://weblog.raganwald.com/2006/09/business-programming-
sim...](http://weblog.raganwald.com/2006/09/business-programming-simply-isnt-
that.html)

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

~~~
kragen
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?

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

~~~
kragen
I am disappointed in the quality of your response.

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

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

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

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

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

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

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

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

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

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

~~~
katz
"I'm not sure there is such thing as an inherently boring software project."

Have you never heard of SAP?

~~~
raganwald
My name is Nikolai B. Round up a couple of friends and I'll give you $6,000
each to build a competitor to SAP. You have only two constraints:

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

Go!

~~~
c00p3r
It was developed almost 30 years ago. It's based on technologies from 80th.
It's don't scale. It's have no community. support. It will cost you a fortune
for pre-start, a fortune for make it work, and a fortune for thousand hours of
sly consulters and fake trainers. It's for medium business.

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.

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

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

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

