
Anti-patterns and malpractices in modern software development (2015) - barry-cotter
https://web.archive.org/web/20160308032127/https://medium.com/@bryanedds/living-in-the-age-of-software-fuckery-8859f81ca877
======
itsmejeff
The best programmers I know write good code within the constraints of a fast
paced business environment and they are also able to clearly articulate trade
offs to stakeholders. They don’t complain about business constraints and they
put out stellar work.

“business people” most often do understand what makes the money flow through
their company (and into engineers’ bank accounts) and they typically make
decisions in order to maximize good business outcomes. Sure they don’t
understand the technical details of an engineer’s work, but the engineers are
far from understanding all of the things that must fall into place besides
lines of code in order for their paycheck to clear. It’s not always vital to
the business to have a good code base. Also, for better or worse, if an
engineer is not of the variety I listed above, they are replaceable in the
eyes of the business.

(fwiw I’m a director-level engineer so I’m technical but bordering on being a
“business person”)

~~~
bcrosby95
In my experience, simply doing the work without complaint is one of the most
inefficient relationships with a programmer. Sometimes changing a minor
business constraint can have an outsized impact on development costs.
Oftentimes these decisions are even made by business people that think they
are making things easier but are actually doing the exact opposite.

~~~
watwut
I have worked in team where programmers constantly questioned business
requirement - without having any understanding of business.

Eventually customer got tired of having to defend how many statuses he wanted
in combobox or what process their company want to use.

By that I want to say, there is definitely such a thing as programmer not
willing to consider business point of view for a second and thus being
impossible to work with.

~~~
zachrose
Sometimes it’s hard to understand the business. I see this happen when
developers are considered fungible resources to implement a spec. If their
only visibility into the business problem is through a proposed solution, then
yeah, questions about how many statuses are supposed to be in the combobox are
to be expected.

~~~
watwut
It was not issue of ambiguity. Specification was clear. It was issue of
programmer assuming that customer is wrong all the time and basically wanting
the customer wrong. The statuses were right, but the programmer fought to
merge few of them into one, because it looked "simpler" to him.

By questioning in don't mean having honest questions nor trying to understand,
but being convinced that there must be mistake and forcing customer to defend
every tiny choice.

And sometimes the customer wants radiobox instead of combobox are just wants
to have it without having to spend 20min on meting to defend the choice.

~~~
agentultra
On the other side I've had customers ask for things that _are_ impossible or
against best practices and their own interests.

For example, password requirements. Many companies are not aware of the latest
best practices and guidelines and request that we block browsers from
generating or remembering passwords in password fields. Or they give us a list
of draconian password requirements that are clearly debunked by the latest
guidelines.

Or they ask us to basically break the HTML spec.

Like I tell my four year old son, _I 'd love to get a million dollars but I'm
not going to get it because I stamp my feet and demand it._

Trade-offs need to be made on both sides. I agree that an engineer that
doesn't provide alternatives when a customer demand is not technically
feasible should be corrected. However the customer should be prepared to
choose from those alternatives or change their demands as well. The first step
to success is shipping and the most common reason for software projects
shipping late is a failure to start. I'm not against firing bad customers.

It's much easier to ship without a contentious feature and figure out how to
add it later than to delay shipping (for certain features within reason, of
course -- please don't ship half-baked security libraries or aviation control
software).

~~~
watwut
Yes, but that is different situation.

I was specifically talking about situation where requirements are possible and
not ambiguos. And where engineers starts "knowing" customer is wrong and keep
knowing it despite it regularly turns out it was enginers lack of domain
knowledge.

There is no trade off between these two situations.

I don't know what you mean by breaking html spec. Browsers keep it and we work
either with it or around it?

~~~
agentultra
Ah okay, that makes sense.

re: HTML -- I've had strange requirements come in that required us to work
around the HTML spec in order to get the UI to work they way they wanted. We
eventually found a better solution...

but the point was that not all requirements are golden; sometimes the customer
is plain wrong, ignorant, and stubborn.

~~~
watwut
Yes, I agree with that. It is not that customer is always right. But it is not
that customer is always wrong either. We have to look at requirements, give
them benefit of doubt, ask and listen to answers to figure out which are
wrong.

------
mindvirus
I think as a profession we've been bad at quantifying and communicating the
value of clean infrastructure and good development practices to the business.
Why should they pay you to make things "nicer"? One of your big customers is
threatening to churn if you don't deliver this new feature! To them, it sounds
like you are asking them for a ton of money for better feng shui -
pseudoscience with unclear benefits - when they can directly see the benefit
of delivering features to the customers.

Instead, I think we need to learn how to measure and quantify the value of a
good codebase and good practices, and communicate that to the business.
Google's error budgets are a step in the right direction here, but I think
there's a lot more that can be done.

~~~
sopooneo
I've been brainstorming this with colleagues at my job and tossed out the idea
of including both an immediate development cost as well as a "long term cost
multiplier" for every requested feature. So far, no one has the like the idea
or phrase. I can't really blame them.

But there must be some quantity or term, with a nice memorable ring to it,
that could get this across and at least let business people make decisions
with full information at hand. Granted, any such numbers delivered in that
guise would be wild guesses. But still, better than nothing.

Edit: However, I've since realized that the notion of "story points" and
"velocity" already sort of provides a way to get this across if used
carefully.

~~~
m_mueller
How can story points be used for that? To me that's only relevant in the short
term. Can management be made to understand that velocity can be too high?

Edit: Expanding with my previous thoughts on this - as a software architect
I've explained my role to management by saying it's like I work in an agile
team, but the waterfall is in my head - someone needs to keep the architecture
together and drive it towards green pastures where it keeps great flexibility
for developing future anticipated features without giving up stability.

~~~
sopooneo
My thought was that story points can be used once they are turned into
velocity by dividing by time. And you can say that adding this feature half
baked _now_ in short time, will inevitably drop our velocity by 10% in the
future.

~~~
m_mueller
Like a huge afterburner that is a dead weight after 3 seconds...

------
petermcneeley
"I suspect that most discrimination that happens against older programmers is
not, in fact, age discrimination, but is, in fact, ‘wisdom discrimination’."

~~~
shantly
As long as hiring and technology decisions remain largely hype-driven, having
someone around who says "we don't need k8s, hadoop, machine learning, and AWS
with some big-ass Terraform-driven constellation of supporting serices for our
expected data, workload, and use case; look, give me one middle-weight server,
or one heavyish VM somewhere, and I can show you how to do all this with awk,
sed, cron, and maybe a few lines of Perl or Python. We can have it up fast and
anyone who can read man pages and a README can admin it, and anyway it's so
simple and the workload static enough that once some initial kinks are worked
out it'd probably run in a closet without issue for so long you'd forget it
was in there—so, longer than this project is likely to be alive, anyway" isn't
really something you want unless you plan to ignore them. For their fellow
developers, that's résumé poison, you _need_ "real world" experience with all
this crap for the next job hunt. For the product manager, owner, and sales,
you can't baffle stakeholders or investors or prospects with fancy bullshit
when there isn't any fancy bullshit.

~~~
ironmagma
It’s always fascinating to me how people can get to this point where they
eschew new technologies just because there is an older way that works fine.
Yes, having a tried and true pipeline is important, but it shouldn’t be
surprising that companies are made of people who want their company to push
the envelope to further evolve the systems. _Someone_ was the first person to
use Python for a production project, and that evolution has to happen
somewhere, with real applications to test them.

~~~
taneq
It’s always fascinating to me how some people churn from tech to tech, burning
most of their time reading docs and fighting with configurations, just because
a new technology might be a bit better than the existing, perfectly adequate
system.

It’s not that things can’t be improved, just that there is so very much low-
hanging fruit that has never been implemented at all in a usable manner. We
should focus on the huge gains to be made there before the tiny incremental
gains to be made by endlessly iterating.

~~~
celticmusic
There was a blog posted on HN or reddit (I forget) talking abou how they were
moving the tech behind their blog yet again. And went through how they did
static when it was popular, reactJS, node, and a few others.

I read thinking to myself "my god, it's just a fucking blog engine, why are
you spending so much time rewriting it in shit, realizing what you wrote it in
has downsides, and thinking the new shiny wouldn't?".

It's like someone actually believe there's a tech silver bullet just around
the horizon, rather than a new way of doing things that eases some burdens and
creates others.

------
yibg
Is it just me or does this article read as basically “everyone else is an
idiot, executives (1), managers (2, 8), architects (3) and other developers
(5, 6, 7) and only I can see the future and know what needs to be done.”

~~~
vorpalhex
The article reads to me as "I didn't get my way and our code isn't perfect,
therefore it's everyone's fault but mine and if only we'd embraced X, this
would have all been avoided."

------
29athrowaway
History of computer programming:

\- Having an accumulator (abacus)

\- Accumulator with operations (calculator)

\- Multiple registers with more complex operations (early computers with
plugboards)

\- Stored program computer (abstraction over the plugboards)

\- Imperative programming (simple abstraction over operations + registers)

\- Procedures, Functions, Structures

\- OOP, functional programming, and beyond.

Why do we keep making layers of abstraction? reusability.

We want abstractions that reduce effort by making code reusable.

But abstractions are only a tool, using the tool correctly is on the
programmer.

Code is written once, read many times. Languages that focus on "easy to write"
are a trap. Languages that focus on "easy to reuse" are what you want.

~~~
gimboland
Abstraction isn't just about reusability; it's also about comprehensibility. I
put a lot of effort into lower layers that abstract away complexity, not so
that my business logic is reusable, but so that my business logic is easy to
write, easy to comprehend, and (within the constraints defined by my
abstraction) easy to modify without breaking things. This does require that
the lower layers, the abstracting layers, are well engineered, with well-
defined interfaces and behaviour, but it pays off, even if reusability is
nowhere to be seen.

~~~
zo1
I highly agree with this. It's almost a necessity these days with a major push
to hire "junior" developers at a discounted rate. By doing those lower
abstraction layers, you allow them to write the necessary high-volume business
code while reducing their ability to do something subtly stupid for the
business/data. Usually this involves abstracting away a lot of the database
transaction-type stuff.

And on a side note: Never let juniors anywhere near the database design
without supervision by the team/seniors. They won't learn anything that way,
and they will inevitably make a mess.

~~~
29athrowaway
In genetic algorithms, you select the best from each generation to breed the
next generation.

I think this holds true in software development teams as well.

When you indoctrinate new developers, you should delegate mentorship to the
best* performing teams, so new developers can assimilate good practices and
develop an intuition for how thing should work.

I think this is much more valuable than giving them grunt work.

*: just like with genetic algorithms, picking the right fitness function is everything. Good performance is about steady, consistent, sustainable development... rather than trading today's problem with tomorrow's problem.

------
tomohawk
What a bunch of huey. I've consulted on government programs with massive
amounts of money and easy to meet deadlines, and the resulting software
systems were still crap. Why? Because yagni (you aint gonna need it) went
right out the window and they ended up creating the most resume padding, shiny
rock encrusted POS ever.

------
ummonk
>Some propose that the phenomenon of easy credit and low-interest rates make
it economically nonviable for a company to act in its longer-term interests.

Wouldn't it be the other way around? High interest rates would increase the
discount rate for future value?

~~~
lazulicurio
I think the idea is that low-interest rates cause investors to push companies
to adopt riskier behavior and that easy credit enables said riskier behavior.

------
agentultra
I don't recall ever having worked on a large code base with a team of
developers where everyone was 100% happy with it. Developers complain about
_everything_. It's never good enough and never will be.

I believe this is related to our brains being hard-wired to prioritize
negative phenomenon and stimuli. Most of those projects shipped and were
successful. Users _did_ like using them. However the developers often only saw
the bug reports and the endless requests for new features. They never got a
chance to talk to users and see how the software was being used and improving
the lives of real people. They only see the barb-wire and duct tape.

I had a young developer ask me once about _refactoring_ : how do you get time
to refactor your code?

 _Never_. You will never find a person willing to hand you a paycheck to take
a month to change absolutely nothing. It gives the business no advantage. _But
the bugs!_ the young developer says. To which I say, dear summer child, _risk
tolerance_. The business is willing to take the chance that 1-2% of the time a
user may get frustrated, encounter a bug, and file a report or complaint. If
the company has to pay you to fix it later that's fine. They can tolerate the
cost.

You refactor your code as you go. After you write the code and your tests pass
and you think you're done -- refactor first. Abstract away superfluous
variables with function application, remove duplicated code, break up long
branches with decision tables, etc. Fix that code up before you check it in.

As you get better your refactor steps will be much shorter as you internalize
the data structures and patterns that lead you to clean, concise code to begin
with.

When you write software commercially you need management that understands how
to balance capital, people, and technology. And you need engineers who are
pragmatic about their work and the real outcomes: the systems and the people
who use them.

~~~
pdimitar
> _You refactor your code as you go._

That's one of my most valuable self-taught truths! I fought with management
and colleagues for _years_ until one day, after a 4-day weekend, it just
struck me: nobody can tell me anything when my PR contains _both_ the desired
feature (or fix) _and_ the refactoring that slightly improves the status quo
of the code.

This was ~5 years ago. From then to today, I hear complaints about my PRs
about 2 times a year.

~~~
dep_b
The word "refactoring" to software managers has the same ring as "prostate
exam" or "speculum" to the rest of us. It might be necessary sometimes but
Preferably Not Today and please stop talking about it all of the time.

~~~
pdimitar
Yeah, agreed. I stopped using it altogether when I am not talking with
programmers. I usually just say "when adding this new thing you have to re-fit
everything else so all parts play nice with each other", or "you know how you
have to pull the engine out so you can fix the frontal suspension? that's what
I have to do sometimes". Both of these are accepted pretty well by non-
technical people.

------
sli
My two bosses keep asking me how the code I write for myself is so stable
(it's Elm), and yet we're always fixing bullshit bugs in our company's
codebases (they're JS and TS -- sorry guys, TS isn't good enough).

But when I try to sell them on the stuff I use personally, the response I get
is "it will be too expensive if we have to hire someone for that," yet no
thought to the cost-effectiveness of needing to calling a dev on a weekend
with overtime pay to fix a null reference that snuck into the codebase during
the week somewhere. Or months ago. I'd say another developer is more valuable
than clinging to classes of bugs that don't need to exist any longer.

We do what we can but can only do _so much_ to make and keep our code stable,
we're a small company with a small dev team and one of the two managers like
to meddle in the code. We get by well enough, but despite all the evidence
directly in front of them, I am simply not allowed to take the leap into
something that would be better in the long run. It just doesn't matter to
them.

Another one I get is "that language is too weird," but I've taken to just
directly telling them that isn't a criticism and that I need a better reason.
Of course it just goes right back to the hiring excuse from above. We aren't
hiring and have no plans to hire anytime soon. We're small enough to move
quickly, there's no giant organization to migrate into new tooling, none of
that, I'm just basically being told that I'm planning too far in advance.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=12778824](https://news.ycombinator.com/item?id=12778824)

a bit more:
[https://news.ycombinator.com/item?id=13270271](https://news.ycombinator.com/item?id=13270271)

------
darepublic
this problem is about as intractable to me as why I don't eat healthier. Maybe
one day I will achieve one or both.

------
purplezooey
There is so much truth in this article I nearly fell off my chair. Especially
#2 and #3.

~~~
shantly
> Oh sure, you can solve the endless little meaningless problems that plague
> the day-to-day life of programmers everywhere, but the source of these
> problems — defects at the engineering level — are effectively untouchable.
> Also untouchable are the systemic issues that cause each of these should-be-
> trivial-to-fix problems into 5–8 hour tasks.

That part of #4 is so true it hurts. Most of the software I use is full of
brokenness and "WTF"s.

About a year ago: AWS Lamba supports Java. Sweet, should be easy. Oh but the
command line tools are broken in several ways you won't discover until you
try, find they're broken, google around for a while trying to figure out
what's wrong, then realize it's not your fault when you find the relevant
unfixed issues.

About three years ago: Well I'm writing an Android app so this Google Maps
feature should be a piece of cake, I mean, Google makes the OS so surely Maps
is amazing on here. Except. Wait. No. That cannot be right. It can't. The
Android maps SDK is missing features that the Javascript version has? No. That
doesn't make any sense. Oh. Here's a GH repo someone already made to provide a
convenient interface from Android Java to the Javascript maps SDK for this
exact reason. I mean I guess I don't have to write it myself now but
seriously, this was a fucking waste of half my day for no good reason.

A few days ago: Debian installer is flat-out incapable of writing Grub
correctly. Several tries, every reasonable combo possible, boot fails with
missing OS every time. This ain't my first damn rodeo—something's wrong. Think
it's maybe a UEFI issue. Force UEFI. Now my video card doesn't work. Because
it's not UEFI compatible? Why dafuq is that even a thing? Open case, reset
bios so I have a display again, install again just to be safe, boot to
installer's recovery mode, mount, chroot, install grub manually and in
_precisely_ the way I'd told the installer to do it the first time, and
without changing a damn thing about the config the installer had just written,
and it's fine.

This is basically how everything goes every time I try to do anything with
software at all. Which is my job. So this is my life.

Software is terrible.

[EDIT] in fact I can think of one area where my tools are consistently as
shitty, broken, and unsuitable for their intended purpose as software usually
is: it's when I cheap out on power or (especially) hand tools to try to save a
buck.

~~~
scruple
There is a related Jonathan Blow talk titled "Preventing the Collapse of
Civilization" [0] that I came across recently from a HN post. You might be
interested in watching it. Also, Casey Muratori's talk titled "The Thirty
Million Line Problem" [1].

[0]: [https://youtube.com/watch?v=pW-SOdj4Kkk](https://youtube.com/watch?v=pW-
SOdj4Kkk)

[1]:
[https://youtube.com/watch?v=kZRE7HIO3vk](https://youtube.com/watch?v=kZRE7HIO3vk)

------
interblag
5sts

------
hootbootscoot
*of

:D

------
albertTJames
This feels borderline sociopathic.. working in team is hard and demand
compromise, and yes, although necessary no political system is perfect. But
the work conditions of a software engineer are way better than any other job I
have done.

------
galaxyLogic
The so-called "Business People" are people who's main goal is to make money.
And if you think about it that really means their main goal is is to make
money for themselves.

Techies' in contrast are more concerned about building great products. This
naturally creates some tension between techies and the business-people. What
should be the division of labor, and rewards?

