
How terrible code gets written by sane people - SarasaNews
http://chrismm.com/blog/how-terrible-code-gets-written-by-perfectly-sane-people/?2
======
JamesBarney
I like the article but I found the implied solution a little humorous.

Just hire devs who are great coders, great communicators, stubborn enough to
push back against upper management, good hearted enough to sacrificed their
own KPIs to focus on the success of their project, and massochistic enough to
stick it out at an obviously poorly run project.

Good luck

Side note, for 15 years of experience the project doesn't seem that bad by a
long shot. I only have ~7 years of experience and have seen some far worse
code. I was just recently on a project that has some methods that take 8 call
backs(project was greenfielded in Jan 2016) before that I was on a project
where the development team copy and paste the source for the last web page
every time they needed a new one, but not delete the initialization code that
fetched the data from.the database. So the 18th screen they worked on had
26,000 lines of code and took 5 minutes to load. And every button click
triggered a reload. So, add a new widget and boom, wait 5 minutes for a screen
refresh.

~~~
kol
I wrote two mails yesterday which basically "push back against upper
management", for a very good reason. At least that's what I think. Now I'm
totally terrified about what will happen tomorrow. I have 4 kids and almost no
money in the bank.

~~~
edblarney
Don't 'push back'. That is the wrong terminology, and it's inherently
confrontational.

Explain to your managers the range of outcomes and give them the power to make
the decision with the best information you can provide them.

i.e. 'if we skip this bit, then quality will likely suffer, with these kinds
of expected outcomes'.

Don't be dramatic or emotional, just try to give the best information you can.

Also have sympathy for them - money does not grow on trees - and basically
balancing quality vs. time-to-market is a constant and difficult challenge.

This way - if they decided to 'rush' it - they know what the likely outcomes
will be and the inherent outcomes.

If they are making the decision then the responsibility falls on them to the
extent that you have provided them with thoughtful and realistic assessment.

~~~
watwut
Pretty much this. Sometimes pushing back is needed, but way more often
"negotiation" is needed. It is unreasonable to expect managers to magically
see into the development details, you have to explain, made plans transparent
etc etc. When you do that you often (not always) find that requirements are
negotiable and not equally important, e.g. it is possible to meet the deadline
without sacrificing code quality. Oftentimes the compromise is possible - you
wont get two week straight of refactoring, but they are ok with using 20% of
development time for cleanups.

I have seen developers "push back for the right thing" in a way that basically
amounted to angry emotional outburst over things manager did not understood.
The dude thought he is pushing for the right thing, but everyone else thought
he does not listen to their needs, refuses to follow the company vision of the
product replacing it by his own. (They wanted simplest possible functionality
and fast, he was constantly adding own requirements to "make it better". When
the same person pushes for yet another refactoring, management does not trust
him.)

The other thing to understand is that some experienced lead remembers teams
that were given time, no deadlines and all the good stuff and then produced
mess anyway, procrastinated and took long time to do it. I have seen that
happen and I have also seen that ended in long wars over petty differences in
style and opinions. Sometimes the mess is result of people doing something
knew and thus bad decisions along the way. Code review alone wont solve that,
because the reviewer may be the one forcing mistake on others.

You need to communicate in the way that will ensure the manager that he or she
is not in the above situation.

~~~
edblarney
There should be no need for 'wars' or even 'negotiation'.

It's the managers decision - not the developers, really.

The devs can lay out what can be done, and describe what the results will be
if various paths are chosen.

'Skip the tests' \- you get quality issues, but better schedule.

'Write perfect code' \- you get quality, but it could take to long.

The old saying: 'fast' 'quality' or 'cheap' -> pick 2.

If your team is having problems because of bike-shedding over details, or
messed up code - this is altogether another issue and needs to be addressed
differently.

------
dahart
It feels like people are focusing on bad conditions and unreasonable
deadlines, and not the idea that in the real world smart people under
execellent conditions do this very, very frequently.

I've worked for long periods of time in 3 codebases that were over 2 million
loc in my career, all had great conditions, all had very smart people. Those
are not huge codebases by any standard, and yet all 3 had people talking about
ground up rewrites. All 3 had people complaining about every single example
the author used. Two of them undertook the ground up rewrite estimating one
year. Both admitted to having made a huge mistake 3-5 years later.

My theory is that _all_ software eventually becomes difficult to maintain and
full of warts, regardless of smartness, regardless of conditions. We all have
code ideals we believe and talk about that don't work as well in the real
world as we imagined. We all have deadlines that are shorter than we want --
it's a universal constant. We all imagine we can write code and fix big
problems faster than we really can. And we all fail to fully understand what's
working right in a messy large codebase and tend to focus on what's wrong.

I don't know how to fix this, but it's very possible the author ran into
thoughtful paradigms he just hadn't seen before and didn't fully understand.
Some styles seem messy if you haven't seen them before.

React is an intentional lack of separation of concerns between code and
markup. Some projects are _required_ to mix tabs and spaces depending on
tools. For that matter, bash scripts alone require mixing tabs and spaces for
some features. And so on, it's important to have context for why things are
the way they are before jumping to the conclusion that it's bad.

~~~
SatvikBeri
> My theory is that all software eventually becomes difficult to maintain and
> full of warts, regardless of smartness, regardless of conditions.

I agree. I think there's a lot of emphasis on preventing bad code from
existing. But if you believe some bad code is inevitable, then it's more
important to make it easy to fix when it happens.

By default, good code tends to be modular and easy to replace, while bad code
is excessively coupled and hard to get rid of. So bad code has a
disproportionate impact on long-lived codebases.

I wonder if one way around this is to force modularity, even when it's
unnatural. Functional programming seems to be one way of doing this,
microservices are another. A related principle would be not to take DRY too
seriously, favoring decoupling over deduplication.

~~~
lloeki
> I agree. I think there's a lot of emphasis on preventing bad code from
> existing. But if you believe some bad code is inevitable, then it's more
> important to make it easy to fix when it happens.

Indeed, what matters isn't writing bad code, but doing so in a way that
affects the whole codebase (whether through coupling or by volume). Accepting
that bad code happens helps a lot in locking it down behind containment
measures, both in space and time. I can liberally accept bad code as long as
it doesn't imply bad architecture, so that it's easily removable and
understandable, but I'm hell bent on refusing any form that means we can't dig
ourselves out of a hole we've dug ourselves into (this includes slowly
drifting yourself into a hellhole by accretion, bad code _must_ come with an
expiration date, which means immediately creating an issue in your favourite
bug tracker upon commit/merge). Decoupling is key, and duplication is often
needed to see the true generalisation patterns emerge, not the ones you expect
to be there sometime in the future[0].

[0]: noop-noop-noop maneuver (video+slides)
[http://www.thedotpost.com/2016/10/katrina-owen-the-
scandalou...](http://www.thedotpost.com/2016/10/katrina-owen-the-scandalous-
story-of-the-dreadful-code-written-by-the-best-of-us)

~~~
SatvikBeri
This is a great talk. I find that this pattern comes up over and over again:
first add new code in a safe way that makes the codebase a bit messier without
modifying anything, then move all functionality to the new code and neuter the
old stuff, then delete the old stuff. Eg this style of pattern is how to do
schema migrations safely.

------
dsego
I work on a lot of projects like this. The non-techies running the project are
usually clueless and programmers are out of touch with modern best practices.
The funny thing is that it makes me look slow for not finishing tasks. People
in charge want to see features banged out. The guys who write hundred-line if-
defs or copy/paste code from one file to another, get to go home at 5pm and
live their life. Someone else picks up the tab later. When they need some info
from the db, they just add an ajax call and some php function to fetch that
and use jQuery to change it on page. I don't even try to refactor this stuff,
just breaks everything, so I go along. I won't even say anything about
cleaning it up, because it will be assigned to me, while the other guys pile
on spaghetti code like there is no tomorrow, good luck merging that.

~~~
amelius
I sympathize with this, but perhaps it is really more economical to write
software like this in your company's case (?)

~~~
Clubber
It appears that way short term, but long term, having a bad codebase can
retard a company's growth through lack of scalability and maintainability
(read easily add/remove/change features). Companies spend a hell of a lot of
money for growth. If they don't know how to manage software development, then
the software will nullify all that cost spend on growing, because the system
can't handle it.

I am truly amazed at how bad many US businesses are at managing their software
systems. It's as if they are considered an afterthought rather than the
department on which every other department depends. It's simply old fashioned
thinking. CEOs are typically older, and the current crop were trained before
computers really proliferated business.

~~~
busterarm
> It's simply old fashioned thinking. CEOs are typically older, and the
> current crop were trained before computers really proliferated business.

It's really not this at all. It's not a generational thing and it's not an
old-fashioned thing. The ultimate rule of workplace dynamics is whether your
position is seen as a cost center or a profit center. In software, most often
your job is treated as a cost center.

My company is the third tech company from a repeat founder who is younger than
me (he's 29) and was previously acquired by a huge tech company. He absolutely
sees the work as I do as commodity and doesn't understand what I do or what
its value is. I've built rock-solid, scalable systems, envisioned and built
tools that will bring us more (and better clients) and saved my company
hundreds of thousands of dollars in a year. If I don't fight for the projects
I want to do and push back against bad ideas, I get tasked with essentially
pointless "tech janitor" work.

I've encountered non-technical executives well into their 60s who deeply
understand the value of tech. You just have to find people to work for that
aren't idiots.

~~~
eikenberry
> The ultimate rule of workplace dynamics is whether your position is seen as
> a cost center or a profit center.

You are right and this should be one of your top check boxes when looking at a
potential employer.

------
joeax
_Focusing on poor metrics such as “issues closed” or “commits per day”_

I once worked at a company that used an offshore company to work on certain
modules of a large project. They would commit code that my team would have to
then code review. We'd see things like large IF-ELSE blocks with minor
differences among the conditions (sometimes just one char). I know everyone
hates this.

Turns out their internal metric was lines of code per day, so they'd bloat the
shit out of everything.

~~~
Clubber
There's an old quote I read and I keep it with me. It was for CEOs and it
says, "You get what you incentivize." The hardest part of managing a group of
people is incentivizing exactly what you want, yet so many people don't spend
an ounce of thought tuning that properly. There's other people who believe
process will fix everything, yet don't bother tuning their process.

Many companies have fallen because the CEOs incentivize net without
incintivizing quality, i.e. gut the company, get your bonus and get out.

~~~
devoply
Code should be reviewed, preferably by a different group of people who wrote
the code, metrics are only useful for people to manage themselves. Upon review
there should be immediate feedback to people who wrote it and if they continue
to make the same errors, then you should eventually get rid of the person who
wrote it. Making up stupid systems of control to "incentivize" people as a
method of management is the stupidest thing rationalists ever cooked up. It
destroys internal motivation and discipline.

~~~
Clubber
>is the stupidest thing rationalists ever cooked up.

Oh, you don't like bonuses then? Unsolicited, forced code review doesn't have
much value that I've found, unless your team is fairly junior. Senior guys
know what good code looks like, even in a crunch. If you hold forced,
unsolicited code reviews with senior developers, you are really just throwing
away money and aggravating people.

It's just another half thought out process. A better incentive, in my opinion
is: if you release a complete codebase with 0 medium and above defects by X
date, you get a free week off, or something of significant value. A free,
company branded desk clock doesn't cut it. (that's happened to me before).

If a company is trying to save money by hiring the cheapest offshore
developers they can, they are still really just throwing away money and
aggravating people. lol. That is a perfect example of a poor incentive: cut
costs without any regard to the resulting cuts in quality. Anyone can make a
turd cheaply, but that's rarely what businesses really want.

~~~
yomly
what about if you reverse the incentives...

Product Managers get bonuses related inversely to hours of downtime (caused by
bugs).

Engineers get bonuses related to number of features pushed out.

In theory, this would encourage engineers to ship as fast as possible whilst
encouraging PMs to ensure quality over quantity wrt feature scope/volume. This
way you'd have engineers begging to add features and PMs begging for tests.

What am I missing - how can this be gamed?

~~~
monk_e_boy
What you cause is stress and tension between the two groups. They start to
hate each other and blame each other. "That's not a bug - that feature was
never in the spec"

------
erikb
Honestly, I think the best developers are not the ones that write beautiful
code and put quality above everything else. The best ones are the ones that
can push out a solution given too little time and given a (maybe self
inflicted) bad code base. Because that's real life, and not the pony farm.
Money trumps everything else in capitalism. Getting money means paying your
bills today. And even more so than skill, quality and code getting money
requires kowtowing and overpromising to someone who currently has money.

Second comes qualifying for the money (yes, in real world you get money
without having what you are selling, but that's a short-term success). That
means getting to ask for money again tomorrow. That is where skill and code
come into play. You promised something and now when you are lucky you can
deliver 80% of that. Push hard to get there. Not everybody who tries will
achieve that much.

And only then comes quality, which means qualifying for money next year
becomes cheaper.

If you realize LIFE is that way, suddenly high quality isn't all that
important anymore, is it? Quality is a luxury and you must have achieved A LOT
to be in a position to just think about quality. And the ohter people
(management, sales) are not total idiots. If you dream the high quality dream
they are the people who pay your bills.

I am an engineer like you, btw. I was just in the situation already, where I
had to pay my bills myself and therefore know what amount of humiliation and
sweat is required to get money just for ONE person, me.

~~~
dasil003
I mostly agree with your top line. Code "beauty" and "quality" are not
objective measures, and there are plenty of devs out there who are obsessed
with their own interpretation of those ideals to the point that it inhibits
their ability to ship.

However there is an existential danger for management to embrace this
philosophy. The problem is the incentives are already naturally aligned to
ship today, and problems discovered tomorrow are likely to fall on the
shoulders of someone other than the original author. If there is no
institutional value towards maintainability, then the code base will get worse
and worse until it grows beyond the cognitive ability of _anyone_ to ship
_anything_ without negative ROI. By the time that happens the cost to fix may
be more than the company can afford.

~~~
erikb
The funny thing though is that tomorrow will resolve itself by itself. If the
next guy finds the code too unworkable it will get replaced or the company
dies out. Either event is not really a problem. Somewhere money is found to
pay the replacement, people find new jobs, new companies take up space opened
by other companies dying.

Everything else comes from the need to pay the bills. What does your landlord
say if you don't pay your rent? What do you say if your boss doesn't pay you?
It's not a management philosophy it's people trying to pay you and themselves.
And even that may fail one day. You're probably doing the same, when you are
like most people going to work every day despite having other quality ways to
spend your time, e.g., reading a great book.

~~~
dasil003
Sure, in the metaphysical sense does anything really matter?

But as a business owner, you don't want your business to die and be replaced
by someone else's business due to technical debt. Just because it's hard to
quantify the cost of technical debt doesn't mean it isn't real and we should
just throw up our hands in defeat.

And lest you think I'm some sort of artisanal code hipster, I spent years
building freelance custom web apps in the $1k-$20k budget range, so I know how
to fucking ship. Also, I've been the tech lead on a Rails monolith powering a
7-figure revenue startup for 10 years, taking it from Rails 1.2 through Rails
4.2 one version at a time.

Knowing how code rot will happen and how business logic will change is
impossible to be sure about, but having some instincts can save a ton of money
down the line. I've received thank you notes for architectural decisions and
commit messages I wrote years ago and had long since forgotten. Not all
businesses will be able to recognize that such value even exists, and the ones
that don't are likely to be a shit show that will never be able to attract an
upper echelon of developers.

The right attitude and experience about code quality can be a huge competitive
advantage.

------
SatvikBeri
One thing I've been thinking about more and more is code that's easy to
delete.

For example, we recently built a data pipeline that did a bunch of processing
and wrote data to a SQL database at the end. For various reasons, there was an
unscalable, quick way to implement the write, and a scalable, slow way to do
it. We wanted to get the product to testing ASAP, so we chose the quick way
initially.

In order to make sure that we could easily replace that code, we ended up
creating a separate write function for each table, where the function did
nothing else except the write. That involved a lot of duplication, but made it
easy to move the tables over to a better method one by one later.

It seems like having functions with one purpose, pure if possible, is a pretty
good way to ensure "upgradeable" code–even if the internals of the function
are messy, you just have to write a new one that copies the same
functionality. Furthermore, I've found single responsibility functions to be
easier to enforce in code reviews than single responsibility classes.

~~~
iaml
What you are describing seems very familiar to the idea in this [0] talk that
I saw mentioned in the other thread on HN. Basically, the speaker argues that
any codebase has a tendency to become a big bloated mess. The proposed
solution to that is writing highly modular code that you can easily rewrite
from scratch in a week.

[0] [https://vimeo.com/108441214](https://vimeo.com/108441214)

~~~
SatvikBeri
This is great! Much more fleshed out than my post.

------
alexeiz
* Giving excessive importance to estimates

Seen this one. It was used as a excuse not to do code reviews because they
cause to miss estimates. "Look, the feature is done, but because of the code
review requirement I cannot mark it 'done' in the project plan." Solution:
abolish code reviews.

* Assuming that good process fixes bad people

This one is a big one. It's everywhere. Especially in big software development
companies, such as Microsoft and Google. They tend to believe that once they
institute a perfect process, everything works out perfectly. Perfect coding
guidelines lead to perfect code, no matter who writes it. Perfect testing
process - testing can be done by monkeys. Perfect project management process -
now we can hire project managers with just basic Microsoft Excel skills. They
don't understand that without actual talent the company enters a "spiral of
death" which is impossible to escape.

* Ignoring proven practices such as code reviews and unit testing

This is done frequently by people who never tried such techniques as code
reviews and unit testing. If you do it consistently through, say, one release
cycle, you start to value those techniques and understand their importance.

Unit testing, for example, helps me to avoid painful debugging complex issues
in production. All features that I unit tested usually just work when
integrated into the rest of the product. In fact, the last bug I had to fix
happened in code that I neglected to unit test, because the unit test setup
was too complex for that component (in itself an indirect sign of a problem).
Unit tests also lead to components usable independently of each other, thus
reducing the overall system coupling.

* Hiring developers with no “people” skills

This is a double edged sword. On one hand a developer who can't communicate
well will eventually produce code that doesn't do what's intended. On the
other hand there are people with too much "people" skills who can't code shit.
They just bullshit their way through. I'd say there are too many of such
bullshitters. A lack of communication skills in a developer is a problem
fairly isolated to that developer. A lack of coding skills in a bullshitter is
much bigger problem that affect many people around him.

------
arcanus
All good examples (such as excessive importance to deadlines, a big no-no).

My question: can they be truly good programmers of they write bad code? Isn't
the essential product of a programmer SLOC and functionality via software? And
if they do that in a manner inferior to another dev, isn't that objectively a
measure of inferiority in their craft?

I've met far too many 'good' programmers who were a net _detriment_ to a
project not to be wary of the term.

~~~
jondubois
Under insufficient time constraints, a good developer will either produce bad
code or no code at all (he will resign from the company). This is extremely
common. The stuff the author said about too much emphasis on deadlines is
spot-on.

Some developers who code really fast might appear like they're being extremely
productive but behind the scenes, you end up having a whole team of developers
who are just fixing that developer's bugs.

For example, if a lead developer doesn't choose the right framework or
plan/design the API correctly, then the consequences of that will keep piling
up over time.

It's really easy to put the blame on people who are doing the 'small work' but
in reality, they might be doing the best work possible under the terrible
constraints imposed on them.

~~~
lawn
> Some developers who code really fast might appear like they're being
> extremely productive but behind the scenes, you end up having a whole team
> of developers who are just fixing that developer's bugs.

This is very prevalent at my job. There are a couple of developers who have a
reputation of being really fast. "Wow, he closed 25 tickets the last hour!".
In reality he mainly rejected them or made quick fixes which didn't work or
created new bugs. A not insignificant amount of time in a recent project I had
was focused on rewriting code said developer had written.

------
lettersdigits
a good programmer should be able to identify bad companies to work for, which
could solve many of the issues displayed in the article. it's much like
choosing a good life partner - choosing a good life partner (instead of a
crazy one) will save you from many troubles that you would encounter if you
married the wrong person in the first place.

ps: i need to tell this more to myself. i already made bad choices regarding
where i work, which forced me to quit those jobs at the end..

(edit: spacing)

~~~
alkonaut
I think a lot of this sentiment overlooks the fact that in most cities the
number of software companies is very limited - perhaps allowing one switch in
a career if there are huge problems or conflicts, but certainly not enough to
allow switching due to e.g poor development practices. What's worse, in these
places the poor devs tend to stick around while talented ones leave because
they either accept moving or they can find remote work due to good connections
or nice SO/GH profiles.

~~~
lettersdigits
you are removing a lot of personal responsibility from the guy who is looking
for the job. If you are born in a 'bad' place (regardless of the reason for it
being 'bad' \- a violent/poor neighborhood, a city without hope for jobs, a
small country-side town with no tech industry at all, etc. etc.) - you should
be responsible for improving your life/moving to a better city/etc.

to analogize from soccer: Messi plays at Bercelona, but is from argentina.
Ronaldo plays at Real Radrid, but is from portugal. if ronaldo stayed in
portugal, which teams would he be able to play with that would even become
close to matching real madrid ? same goes for messi and barcelona. he could
have said something like 'i was born in argentina, and no one here plays
soccer like barceolna/real madrid. therefore - i will not play soccer because
i was born in the wrong place'

~~~
alkonaut
I think a lot of what you are saying makes sense, but also at some age and
family status (kids in schools etc) moving doesn't make sense any more, or has
more downsides than one is trying to avoid.

Obviously one could have thought of this _before_ marrying and putting kids in
school in the town with one tech firm - but that doesn't make it any less a
reality for a lot of people.

Saying "kids we have to move because dads colleagues refuse to do proper peer
reviews" just doesn't taste right :)

~~~
lettersdigits
> Obviously one could have thought of this before marrying and putting kids in
> school in the town with one tech firm

this was going to be my response, but then you said it yourself :)

The more intelligent and self-responsible act (which is hard, i know) would be
to move to a better place before making extremely serious life choices such as
marrying and having kids. same goes for partner finding - don't marry a crazy
partner and then say 'I married a crazy partner and now we have 2 mutual
children. i cannot leave, i am stuck with this crazy person who is also the
parent of my children.'

and i know it is hard to find a non-'crazy' employer and a non-'crazy'
partner- but this should be your goal and target, shouldn't it ?

also, you get better as time goes by, even if you don't want to (as long as
you are a bit intelligent) - bad companies/life partners will present
themselves as red-flags on an interview/date . and it is your responsibility
to detect those red flags .

(edit: refactor the last paragraph)

~~~
alkonaut
I guess what I'm saying is that a) job market is only one factor in deciding
on where to live. A partners job situation, access to other things in life,
being close to family etc often weighs in, and is often even more important
than other factors. Obviously after such a choice one shouldn't be whining
about limited job market - but the point is that only improving things by
leaving bad companies is not always the solution. For many it's important to
be able to change bad culture as well.

aspect b) is that company environments change, and the fun startup can become
a terrible enterprise in a decade.

I wouldn't advise against working in tech in small towns because of the risk
of getting stuck in the only gig in town. I _would_ however advise that it be
factored into that career decision. One might need to fight to improve company
culture, whereas in Silicon Valley one would instead take a job across the
street. I'd also recommend keeping an active contact network and online
profile so you can get remote work should it be necessary.

------
partycoder
Imagine you have a sales team. Initially you tell them: sell $10000 in 1 week.
Most of them will go through the traditional selling process. One of them will
make a loan on behalf of the company for $10000, and hand you the money right
away.

If you are smart, you will say that you are not interested in having that
money if it comes from a loan. If you are not smart, you will say: "wow, this
guy is a 10x salesman, we will give him a bonus". Meanwhile the company gets
into an unpayable debt beyond any possibility of paying.

Then, when the company is about to die from debt, they declare bankrupcy and
start over or sell themselves to be acquired.

Now, imagine it's not salesmen, but software engineers, and it's not actual
debt, but technical debt, and it's not bankruptcy but starting your project
again.

------
codingdave
The other way terrible code gets written by good developers is focusing more
on deliver working code that meets the business needs, more than elegant code
that meets the needs of future maintainers.

Ideal code meets both. I'm sure we all agree on that. But when working on
deadlines, under pressure, with poor management, you sometimes write bad code.
And if the code is 15 years old, that great engineer you are talking about
today was, at the time, an inexperienced new coder. So you didn't inherit his
greatest work. You inherited his embarrassment where he made mistakes.

I suspect the original authors of the terrible code in question could give
much deeper insights into exactly how and why it was done that way.

------
lunz
Perhaps the team planned a rewrite long ago and stopped worrying about the
quality of their code, which seemed obsolete in the moment it was written.
Over the years, however, there was always something more important than the
"soon-to-be" rewrite.

------
Animats
Converting Python to node.js seems terrible in itself. Converting to Go might
be useful, if you need more performance or scalability.

~~~
ManlyBread
[citation needed]

------
pmarreck
> When I found out I would be working on porting an old Python codebase to
> Node

"Out of the frying pan and into the fire" is not a programming direction I
would recommend. (I don't think I've met a single Node developer who isn't
bitching about it.)

------
NumberSix
A number of points in the post/article are questionable.

First, it assumes the developers had substantial control over the schedule for
the project ("Giving excessive importance to estimates"). Certainly in my
experience this is unusual. More frequently, the schedule is dictated by
management, frequently by sales/marketing executives in commercial software
development. It is _very_ difficult to push back and a good way to lose your
job.

Sales: We have closed this great deal with BigCorp. Can you do X (complicated,
challenging software project) by the end of the quarter?

Developers: Err, um, X sounds like a project that will take six months.

Sales: We really need to make our quarterly numbers. Our CEO Bob used to be a
developer and he says any _competent_ programmer can do it and we only hire
the best. Competent doesn’t cut it here! You are a rockstar ninja, aren’t you?
Can you prove you can’t do it by the end of the quarter?

Developers: Well, no. The schedules are driven by some unexpected problem or
problems that usually happen. But, well, if _nothing_ unexpected happens, we
can do it by the end of the quarter.

Sales: Great! Bob is expecting results by the end of the quarter.

So much for the beautiful, elegant software design methodologies taught in
college and university CS programs and peddled by high priced consultants.

Second (“Giving no importance to project knowledge”), high technology
employers seem to have extremely high turnover rates of software developers
and other employers. Payscale produced a study claiming that the average
employee tenure and Amazon and Google is only one year. Many companies seem to
target employees with more than seven years of paid work experience — Logan’s
Run style — for layoffs and “constructive discharge,”
([https://en.wikipedia.org/wiki/Constructive_dismissal](https://en.wikipedia.org/wiki/Constructive_dismissal))
where employees are made uncomfortable and quit “voluntarily.” Undoubtedly,
this is costly as the author implies, but it seems to be common practice.

Yes, metrics like “issues closed,” “commits per day,” or “lines of code” don’t
work very well. Once employees realize they are being tracked and evaluated on
some metric, they have a strong motivation to figure out how to manipulate the
metric. Even if the employees don’t try to manipulate the metrics, the metrics
all have serious weaknesses and map imperfectly to value added (biz speak).

Third, are code reviews and unit testing proven processes especially for
normal non-Microsoft companies? In the early days of Test Driven Development
(TDD), Kent Beck and his colleagues made numerous claims about the success of
Test Driven Development in the Chrysler Comprehensive Compensation System (C3)
payroll project, an attempt to create a unified company wide payroll system
for Chrysler. This project in fact had a range of problems and was eventually
cancelled by Chrysler in 2000, without replacing the Chrysler payroll systems
successfully.

As the problems with C3 have become well documented and well known, TDD
enthusiasts have shifted to citing studies at Microsoft and some other
gigantic companies that claim practices like TDD and code reviews work well.
Are these really true or do these case studies have hidden issues as C3 did?

Further, Microsoft, Google, and other companies that have played a big role in
promoting these practices are very unusual companies, phenomenally successful
super-unicorns with sales in the range of 40-100 billion (with a B) dollars
with near monopoly positions and anomalously high revenues and frequently
profits per employee. Microsoft claims to have revenues of $732,224 per
employee. Google claims an astonishing $1,154,896 per employee.
([http://www.businessinsider.com/top-tech-companies-revenue-
pe...](http://www.businessinsider.com/top-tech-companies-revenue-per-
employee-2015-10/)) This compares to $100-200,000 per employee for most
successful companies.

Fergus Henderson at Google recently published an article on Google’s software
engineering practices
([https://arxiv.org/abs/1702.01715](https://arxiv.org/abs/1702.01715)) with
the following statements:

 _2.11. Frequent rewrites_

 _Most software at Google gets rewritten every few years._

 _This may seem incredibly costly. Indeed, it does consume a large fraction of
Google’s resources._

Note: “incredibly costly”

Companies like Microsoft and Google have enormous resources including monopoly
power and can follow practices that are extremely costly and inefficient,
which may work for them. Even if these practices are quite harmful, they have
the resources to succeed nonetheless — at least for the immediate future, the
next five years.

From a business point of view, it may even be in the interests of Microsoft,
Google, and other giant near monopolies to promote software development
practices that smaller competitors and potential competitors simply can’t
afford and that will bankrupt them if adopted.

Both code reviews and unit tests are clearly time consuming up front. Code
reviews using tools like Google’s Gerrit or Phabricator (a spin-off from
Facebook, another super-unicorn) are committee meetings on every line of code.

Regarding:

 _Imagine my dismay when I had to collaborate with a colleague on that legacy
project and his screen displayed Notepad in its full glory. Using “search” to
find methods might have been rad back in the nineties, but these days,
refraining from using tools such as modern IDEs, version control and code
inspection will set you back tremendously. They are now absolutely required
for projects of any size._

Using “search” to find methods was not rad back in the 1990’s. IDE’s and code
browsers specifically have been in widespread use since the 1980’s. Turbo
Pascal
([https://en.wikipedia.org/wiki/Turbo_Pascal](https://en.wikipedia.org/wiki/Turbo_Pascal))
was introduced in 1983 and featured a fully functional IDE, soon to be
followed by IDE’s in many other products. Version control dates back at least
to SCCS
([https://en.wikipedia.org/wiki/Source_Code_Control_System](https://en.wikipedia.org/wiki/Source_Code_Control_System))
which was released in 1972. RCS was released in 1981 and version control was
common in the 1980s and since.

Code reviews have been around for a long time. However, in the 1990’s and
earlier they were restricted to relatively special projects such as the Space
Shuttle avionics where very high levels or safety and reliability, far beyond
most commercial software, were required. This speaks to the “incredibly
costly” quote about Google above.

Without more context, it is difficult to evaluate the use of Notepad. Simple
code/text editors like Notepad and _vim_ (formerly _vi_ ) are very fast to
start up and can be a better option for some quick projects than starting an
IDE.

Some IDE’s are particularly hard to use. Early versions of Apple’s Xcode circa
2010 were particularly difficult to use in practice; it has improved somewhat
in the current releases.

People vary significantly. Some developers seem to find stripped down tools
like _vim_ or Notepad or Notepad++ (on Windows) a better option than
complicated IDE’s. I am more of an emacs or IDE person.

The fact that someone else works differently than you do does not mean they
are worse (or better) than you. The fact that something works well for someone
else also does not mean it will work well for you — or vice versa.

There are sound reasons for duplicating code, cutting and pasting, rather than
creating a function or object called in several location in the code. If the
developer anticipates that the code may subsequently diverge, then duplication
is often best.

Like grand master chess players, highly experienced developers, especially
under tight time constraints (like a chess tournament), code by intuition, not
by laboriously reasoning out every step. If it feels like the code is likely
to diverge in the future, duplicate. If it does not diverge, no problem, it
can be merged back later if needed.

In the bad old days of structured design (1980’s) and object-oriented design
(OOD — 1990s), software development projects suffered from Big Design Up Front
(BDUF), grandiose attempts to design a perfect software system before writing
a line of code. This often resulted in massive cost and schedule overruns and
total failures. It often proves better to just throw (“hack”) something
together quickly — a prototype, proof of concept, Minimum Viable Product
(MVP). Just “get something working.”

Inevitably these prototypes and early stage software projects are going to
compare poorly to some theoretical perfectly designed system with 20-20
hindsight. That is what seduced people into BDUF twenty, thirty years ago.

Modern Agile software development methodologies are foolishly trying to have
it both ways, have an initial quick iteration BUT that first iteration should
be perfectly designed up front — beautiful, elegant, with hundreds of tests,
endless committee meetings on coding style and design (code reviews), all
sorts of supposed best practices, no code duplication, etc. This is a
seductive fantasy doomed to fail in most cases.

------
bartread
I sort of lost the will to read further at this point:

"An important component of this project was the focus on deadlines, even to
the detriment of code quality. If your developers have to focus on delivering
rather than on writing good code, they will eventually have to compensate to
make you happy. "

AAAAAAAARGH!!! Seriously? What do you think you're there for?

Good code can be a means but never an end. Of _course_ you're there to
deliver. And of course it's more important to do that than to write beautiful
code.

Give me strength.

------
mannykannot
"The authors created their own framework..."

I cannot say this was an issue here, but I can say that some of the worst
messes I have seen have followed from this decision. In all such cases in my
experience, it was not a technically justifiable decision, and I strongly
suspect it was driven by developer ego and overconfidence.

The very worst included a roll-your-own language.

~~~
Pica_soO
Eh, DSL scripting languages have a right to exist.

~~~
mannykannot
If someone was suggesting otherwise, you might have a point worth raising.

But now that you have introduced this non-sequitur, I will freely assert that
our rights trump those of _bad_ DSLs to exist. I suspect that if you had seen
the specific case I am referring to, you would agree.

------
doggydogs94
The key word is "deadline". Horrible code that works beats beautiful code that
has not been thoroughly tested.

~~~
JustSomeNobody
Along those same thoughts, you put many developers in a room and they end up
converging on "the one true architecture" and nothing ever ships but you have
this monstrosity with some very beautiful code in it. Put few developers in a
room and you get decent code and a solution to the problem that actually
ships.

------
hinkley
I work with a team that managed to write the code he describes in a little
over three years. it's really just chaos and I only trust a few of them. So
why do I keep talking myself out of looking for a new job? Hell if I know.

------
EliRivers
"mixed spaces/tabs for indentation"

If that's the second thing in the list of problems, the problems aren't nearly
so bad or the author's got a savage case of mixing in the trivial with the
important.

~~~
jinglebells
I'd say it's like smelling smoke. If your team can't even agree on a standard
indent and stick to it, and you haven't got a linter which picks it up, what
else are they missing?

------
peter_retief
I had a quick look at your commentary, its great, the whole issue of rushing
code and debugging forever, also nice allusion to anti patterns :) I have
bookmarked and will read properly very soon, maybe

------
macawfish
I know how. Cause I just wanna get something done!

Then later I come back and rewrite it with a dose of _patience_. Then my code
is much better.

------
jelder
Mirror?

~~~
innerspirit
[https://ponyfoo.com/articles/terrible-code-sane-
people](https://ponyfoo.com/articles/terrible-code-sane-people)

------
pfarnsworth
This is a fucking arrogant article. I would love to see this blogger try to
maintain a large codebase after several development cycles in the real world.
To come into someone else's codebase that has umpteen number of iterations and
tough business realities like trying to make money, and proclaiming that it's
terrible code and how he would fix it, is delusional and self-aggrandizing.

Most production code needs to be revamped every few years because the
subsequent unforeseen functionalities that was forced by product managers and
customers. That code is usually going against the grain of the original code
but you can't blame the original designers because it was never spec'ed out.
The best code is the code that is easiest to manipulate and modify, but even
then it gets old and needs a rewrite. There's nothing wrong with that, except
thinking you can comment on the shitty code and thinking your above it and how
you would never let it happen.

~~~
lettersdigits
> The best code is the code that is easiest to manipulate and modify

this great (IMO) article comes to mind:
[http://programmingisterrible.com/post/139222674273/write-
cod...](http://programmingisterrible.com/post/139222674273/write-code-that-is-
easy-to-delete-not-easy-to) :

"Write code that is easy to delete, not easy to extend"

~~~
robnagler
Excellent article, thanks.

------
pmarreck
The site is now 404'ing so I guess s/he isn't heeding their own warning?

~~~
williamdclt
500'ing for me. A lot of websites ending up on HN frontpage aren't dimensioned
for the traffic it implies, I won't blame them for it

------
sadfsa
>porting an old Python codebase to Node

Node is how.

