

Some lesser-known truths about programming - AndrewDucker
http://dotmac.rationalmind.net/2010/08/some-lesser-known-truths-about-programming/

======
wccrawford
The first few, I don't fully agree with. I think the numbers are exagerated.
But these 2 have more truth:

"Although most software is made by teams, it is not a democratic activity.
Usually, just one person is responsible for the design, and the rest of the
team fills in the details."

When things are designed by 1 person (IME) they work better and have a more
flowing work flow. Designing in a committee has been a freaking nightmare.

"Programming is hard work. It’s an intense mental activity. Good programmers
think about their work 24/7. They write their most important code in the
shower and in their dreams. Because the most important work is done away from
a keyboard, software projects cannot be accelerated by spending more time in
the office or adding more people to a project."

While I don't 'code in the shower', I do think about my projects constantly.
An 'ah hah!' moment can come at any time. Just the other day I left for lunch
and in the car on the way I thought of a possible reason for an issue we were
experiencing. I was getting nothing while staring at it.

~~~
cagey
"When things are designed by 1 person (IME) they work better and have a more
flowing work flow. Designing in a committee has been a freaking nightmare."

I completely agree. Yet in industry, being that one person (like I am) leads
to great management consternation to the tune of "what if you're hit by the
proverbial bus?" which leads to "you need an understudy", which leads to
expending 2x the resources to achieve <2x results (the time spent selecting,
training and guiding an understudy is definitely nowhere near 0, even when the
choice of understudy turns out to have been a good one), and there can't help
but be some feeling of "training your replacement". Industry loves
interchangeable parts (people), and a one-man-band (domain expert or similar)
grates against that ethos.

~~~
mseebach
I hate the proverbial bus. It seems to assume that central employees should be
completely dispensible.

If a key employee, being the architect or even the CEO, is hit by a bus, the
company _will_ take a hit. If employees are a central, strategic assets, you
can't go around killing them off and expecting no impact on your business.
Deal with it.

The important metric is whether the company/project can recover, if it is
resilient. Just because one guy drives the decisions, it doesn't mean that the
team filling in the details don't know the code and the motivations behind it,
and there can't be a guy from that team who could take a promotion, or that
the team couldn't be reasonably productive for a while, while a new architect
is brought on.

~~~
noblethrasher
In short, stakeholders should always be concerned with the potential
discontinuity of (especially high) performance. But it's rather like technical
debt (or any other kind); something that should be _managed_ rather than
avoided at all cost.

------
alexkearns
Not so much lesser-known truths as absolute bullshit.

The author describes developers who spend much of their time writing code as
"lazy, ignorant and arrogant". I think it is the author who is being lazy,
ignorant and arrogant in thinking that he knows the truth about programming.

And the idea that a developer will only write a handful of lines of code each
day that will end up in the final product might be true for a developer
working on an established piece of software but anyone who has worked for a
start-up or on their own software will just laugh at the idea of writing just
12 useful lines of code a day. A good developer can easily do hundreds, if not
low thousands of lines of code in a day if pushed, and this code does often
end up in the final product.

Plus, he seems to think that a great programmer is someone who connects
together bits of code created by others, rather than writing his own code.
That's ridiculous - is someone who uses another person's code a better
programmer than the person who wrote the code he is using, in which case I am
a much better programmer than John Resig, say, because I simply use jQuery
rather than having written it myself.

I think this article is a perfect demonstration of the Dunning-Kruger effect.
Sorry for being so blunt but the article bloody annoyed me.

~~~
nocipher
There is some truth in the article. Coding is easy. It's all the other aspects
of software development that are difficult. I know that the biggest hurdle for
any programming project I've ever been involved in is deciding what will be
the different parts of the system and then how those parts will interact. Once
I start writing code, I can program very quickly because I don't have to make
hard decisions.

Even so, a few thousand lines of a code a day is a bit much for anything non-
trivial. To write that much code in a single day means that person must have
done little else besides coding. Unless there was a period of about a week of
design before that kind of coding, I'd expect the code to be rather kludgy
because everything would be decided immediately. A few thousand lines of code,
though, is definitely not something I'd consider average.

A /small/ project that added a new feature to an existing system took about 30
hours for the initial version over a two week time period and about 800 lines
of code. Granted, I don't know exactly where my programming abilities lie
skill-wise, but I can't imagine someone being 30x or 40x more productive than
that as you suggest.

And maybe I'm just new around here, but if was going to argue for the Dunning-
Kruger effect, I'd begin by arguing that I am clearly not suffering from the
effect myself.

~~~
ntoshev
Don't worry about the lines of code you write, I'm pretty sure even Dr Norvig
can't write 50 of these per day: <http://norvig.com/spell-correct.html>

------
dimitar
What makes programming so unique?

Why cannot we generalize?

I think most of the same conclusions apply to teachers, lawyers, salesmen,
marketers, architects, physicians, nurses, engineers and scientists, whatever.

Wherever knowledge is valued in a job and there are intricacies lots of
research, smart planning and thoughtful execution with a great commitment is
going to make the worker a lot more productive.

~~~
yummyfajitas
Programming isn't unique in the set you list, but it is unusual.

Engineer, scientist and programmers are probably in an unusual situation -
they are exploring a primarily unknown solution space.

Most jobs live in the well explored, primarily understood areas of solution
space, and consist of simply applying already known solutions repeatedly.
Teachers, doctors (mostly) and most nurses just perform a set of rote tasks of
varying complexity. The best way to improve performance in these fields is to
write a script/checklist/decision tree and order everyone to follow it.

(In the case of doctors, I exclude a few at the very high end. Most doctors
are not House.)

~~~
jacquesm
I'm with you on the scientist and the programmer, but the whole purpose of
engineering is to work explicitly within the known solution space to be able
to guarantee the outcome of their work.

Engineering is applying the lessons of science to achieve predictable results.

~~~
yummyfajitas
You are applying the term "solution space" in a manner I didn't intend. It's
certainly true that an engineer isn't discovering new physics, just as most
programmers are not discovering new complexity classes or doing fundamentally
new CS. A good chunk of engineering consists of applying existing physical
principles in new ways.

Of course, there are engineers building yet another overpass/HVAC/etc just as
there are programmers building yet another CRUD app, or scientists sequencing
the DNA of yet another bacteria. And now that I think about it, they may make
up the majority.

In that case, most pf programming is not so special at all.

------
ww520
A dentist friend once asked me why is software development so difficult and
cost so much. I told him that's because a competent developer has to become an
expert in the domain of the application in addition being an expert in
programming. It's like learning a new field every time you develop a new
application.

~~~
vog
This is so true.

Often, people try to circumvent that problem by providing complete specs
upfront. But those are doomed if they lack the old problem, i.e. if they were
written by people who are missing expertise in either programming or in the
domain.

Another way to circumvent the problem is to establish a good communication
flow between the domain experts and the software developers. However, that
only works when this intense communication eventually makes at least one
programmer a domain expert. So that strategy is more a way to reach this state
rather than to circumvent it.

Whenever a software project works really well, there'll bee another
interesting phenomenon: The developers acquire a deeper, more abstract
knowledge about the work practices than the workers themselves.

------
Juha
I somewhat disagree with the point that good programmers think about the
problems 24/7. Even good programmers loose motivation if there is bad company
culture or some other de-motivating factors. I find that true motivation and
true interest for the project are very important in software development but
so many companies neglect it.

~~~
thingie
Well, 24/7. That's simply too much. I had (well, still have) real-life
problems that I not even closely think about 24 hours a day, all the week, for
the last half year, and I don't get better in solving it. No. I'm slowly
getting mad.

------
diego_moita
Actually, most of these truths should be very well known; I've seen them
thoroughly explained and documented in books like 'Code Complete',
'Peopleware', 'The Mythical Man-Month', 'Refactoring', etc.

If there are people thinking they're bullshit, then the author is twice right.

------
palish
_It’s easier to throw away bad code and start over than to change it._

You had me nodding along until I came across this. This single sentence is not
just wrong, it's _so_ wrong that it unfortunately calls the rest of the
article into question.

~~~
hnal943
It _is_ easier. Whether it's better or faster is another question.

~~~
palish
The whole reason to even list any programming truths is because they would
make you a better and faster programmer.

~~~
bconway
_The whole reason to even list any programming truths is because they would
make you a better and faster programmer._

Says who? Truths are not always _good things_. That doesn't make them any less
factual.

~~~
palish
I'd say having a firm grip on reality can only make you a better programmer.

~~~
loup-vaillant
You. Not others. If _you_ stop writing bad code, that doesn't stop others to
write bad code. That doesn't mean you won't _maintain_ bad code.

------
j_baker
You know, I'm always skeptical about any article that refers to "truths". Why
is it that we are so intent on there being just one "true" way to be a good
programmer? Can't we accept that there are multiple paths to becoming good?

~~~
stingraycharles
Not only are there multiple paths to becoming good, but "good" depends
entirely on the requirements. In a start-up, a good programmer often is a
programmer that has the ability to complete requirements as fast as possible.
You don't want a start-up developer writing 10 lines of code a day on average
while being on the hunt for the "best" solution, if there even exists such a
thing.

It all totally depends on context, and these articles always use the context
from which the author is biased.

------
vog
_> Bad programmers write code which lacks conceptual integrity, non-
redundancy, hierarchy, and patterns, and so is very difficult to refactor.
It’s easier to throw away bad code and start over than to change it._

Note that there's an interesting way in between. That is, refactoring code
with the explicit goal of eventually replacing everything. There are several
strategies to achieve that.

Those techniques proved to be less expensive and especially less risky than
rewriting everything from scratch. They work because although the old code has
an ugly design, it still has a property that is worth keeping: It is working
and (mostly) debugged code. Undervaluing that property is the root cause of
the many failed attempts to rewrite big software systems.

------
Typhon
There's nothing wrong with this article in my opinion, except for the title.

« _Some lesser-known truths about programming_ » sounds better than « _A few
things that those of you who never read Dilbert don't know about programming
with a team for a big company_ », i guess, but the latter is much more
accurate.

------
extension
One that always seems to surprise non-programmers: there is no authoritative
certification or regulation of programmers, the companies they work for, or
the programs they produce. Being a software engineer requires no more
credentials than playing the accordion on a street corner.

------
tomlin
Something funny about the subject and this site giving me a "Error
establishing a database connection" error.

