
People who disagree aren't trying to make things complex - lmm
http://m50d.github.io/2018/12/11/people-who-disagree
======
ilaksh
A big part of this is that programmers have different programming worldviews.
Many people seem to be unaware that worldviews are not perfect rational easily
modifiable constructions but are instead foundational structures that thinking
builds upon automatically. Programmers are about as unlikely to easily change
their programming worldviews as they are to change their political beliefs.

Which is not to say that programming worldviews can't change, it's just that
by their nature it takes a strong effort to change then and the changes are
usually gradual over time. Or something completely irrational changed them.
For example if a programmer needs to find a new job and the team has a
different approach to programming, this social circumstance may necessitate
that he adopt a new viewpoint.

I think that people are less rational than they think they are. Which is not
to say that they can't be rational, it's just that other preformed factors
besides logic have a strong influence over our perspectives on a particular
topic.

So we can certainly discuss things productively but we should be aware that
people can't change their religion easily. And no matter how smart or rational
everyone has strong beliefs because that's just how our brains operate.

One consequence is that when trying to have rational discussions it is
necessary to try to dig in to identify all of people assumptions, since there
is a good chance of of the other person's programming beliefs may play a big
role in their thinking and you may not even be aware of it.

~~~
dmreedy
This is a great comment, and very succinctly put.

Somewhat incidentally, but I believe this is a large part of why, to me,
software development is not an engineering discipline. At the end of the day,
engineers (I think; not actually _being_ one myself) have to answer to
physics. The 'possible model space' is relatively constrained, and everyone is
working under, roughly, the same set of assumptions, rules, and standards.
This kind of constraint allows for higher degrees of rigor, because there
often _is_ a 'right way' to do things, or an empirical set of tests to verify
the quality of an idea.

Software is, on the other hand, only slightly more constrained than
mathematics in its most basic form. We can introduce artificial constraint by
monopolizing a domain with certain ideas that have proven robust and reliable
(in the same way that we've decided that, in general, you turn a screw
clockwise to tighten it), which in turn allows for the introduction of _some_
engineering-style rigor and standards, but there's nothing really stopping you
from stepping back and saying, "well I want to do it this way instead", in the
way that an Engineer _is_ prevented, by physics, from saying, "well, I think
we should just alter the density of air so that we don't need to worry about
lift for these airplanes we're building; they'll just be buoyant!". By and
large, you _can do that kind of thing_ in code; you're building the world
_within which_ you're going to solve the problem, and you can arrange that
world as you see fit (by and large) to make certain aspects of the problem
easier (often at the cost of making others harder), in the same way a
mathematician does.

And if you've got one kind of world you really like, because it works well
with how problems decompose in your head, it can, to the parent's point, be
really difficult to understand why another representation might be just as
useful to someone else's particular brain arrangement.

Not trying to make value judgement here, though I do envy and admire
engineering rigor. Just a (likely naive) take on a fundamental difference.

~~~
klodolph
> Somewhat incidentally, but I believe this is a large part of why, to me,
> software development is not an engineering discipline. At the end of the
> day, engineers (I think; not actually being one myself) have to answer to
> physics.

As a software engineer who calls what I do "engineering", I have to answer to
physics every day. The difference is that the relative cost of everything is
skewed so far out of proportion to what other engineers work with that it's
hard to account for the differences, and software engineers work with so many
orders of magnitude. We are still working with physical stuff, basically
refined sand and metal, which consumes electricity and other resources, just
like other engineers.

Imagine that you were a civil engineer tasked with building a bridge. Except
instead of using concrete and steel, I handed you some adamantium at the low,
low cost of $0.01 per cubic meter, and a bunch of robots to machine it for
you. Designing bridges is easy now, and you can basically make it look like
whatever you want, just because adamantium is so amazing.

But just because we've made bridge-building trivially easy doesn't mean that
civil engineering is obsolete. Adamantium is nice, and all, but now I'm asking
you to build a Dyson shell, and you have to tell me that it's not physically
possible, even with adamantium.

I would love to just handwave the design of the systems I work on, I would
love to just arrange pieces however I felt like. Instead I have all these
constraints like the reliability of components (hard drives fail), physical
laws (speed of light constrains network latency), the memory hierarchy (the
software manifestation of constraints on circuits), and all sorts of other
problems that I can't just pretend don't exist. I have to choose algorithms
that will complete with the computational resources that I have available.
Maybe an exact algorithm is not physically realizable, maybe I have to choose
some kind of approximation.

This is not true in mathematics. In mathematics, algorithms are not necessary
(at least, for most mathematicians). In mathematics, I can prove that some
object exists without concerning myself with whether some physical system is
capable of constructing that object.

At the end of the day, I am writing software, and that software is one part of
a real, physical system which obeys physical laws. This makes me an engineer.
Maybe I play around with 20 orders of magnitude in my designs and the civil
engineer plays around in 8, but so what?

~~~
flukus
> At the end of the day, I am writing software, and that software is one part
> of a real, physical system which obeys physical laws. This makes me an
> engineer.

The person that made my coffee this morning is also an engineer by this
definition.

Apart from that I agree, we have real constraints to deal with and we can't
hand wave away the environment the code runs in.

~~~
klodolph
> The person that made my coffee this morning is also an engineer by this
> definition.

The verb choice is important here, someone who makes coffee doesn’t “write”
coffee.

That said, any definition outside mathematics or logic is imperfect.

------
btilly
Since this seems to be the place for personal views, my views, after 20 years
of experience, is that people do not notice the complexity of anything that
they have digested as normal. As a result doing anything other than what they
are used to seems very complex to them. Whether that other thing is actually
complex to a neutral third party is situation and observer dependent.

I have seen this with procedural programmers struggling with OO code. OO
programmers struggling with functional techniques. Programmers of all kinds
seeing a new framework. Programmers used to more structured code trying to fix
shell scripts. React developers encountering code using older JS libraries,
and developers comfortable with older libraries encountering React. And so on
and so forth.

In all cases the common denominator is that the programmer is uncomfortable
with the new way of doing things. And the first reaction is, "What's wrong
with this code?" And "It's messy and complex" is one of the easiest
conclusions to draw.

~~~
userbinator
_people do not notice the complexity of anything that they have digested as
normal_

...which is why examples of "minimal complexity" code often provoke feelings
of extreme unease and horror; one nice example is
[https://news.ycombinator.com/item?id=8558822](https://news.ycombinator.com/item?id=8558822)
where the functionality:code ratio almost seems impossible at first glance.

 _I have seen this with procedural programmers struggling with OO code._

To be fair, a lot of OO code tends toward overengineering and premature
abstraction.

~~~
munchbunny
_To be fair, a lot of OO code tends toward overengineering and premature
abstraction._

And a lot of functional code tends towards unnecessary levels of indirection
through higher order functions as a way of deferring responsibility for actual
logic, or on the flipside insufficient abstraction leading to difficulty
extending functionality.

I've gone back and forth multiple times between functional practices and OO
practices, and I definitely empathize with the confusion going in both
directions. You trade one problem for another, and in the end there really is
no free lunch.

React Redux is a great example. People who have gotten over the hump of the
boilerplate involved in threading state up and down the tree love how little
energy they're spending routing state changes to the correct destinations.
However, to someone who is used to event-based UI programming, this looks like
a horrific waste of energy reminiscent of how a giraffe's laryngeal nerve goes
all the way down the neck then back up. They've both got a point, but you have
to follow their paths to see it yourself.

~~~
js8
"I've gone back and forth multiple times between functional practices and OO
practices, and I definitely empathize with the confusion going in both
directions. You trade one problem for another, and in the end there really is
no free lunch."

I think there is a strange kind of duality between OOP and FP. I think OOP
passes structures of objects hidden behind interfaces, while the FP passes
composed functions in other direction. So you can convert your OOP code to FP
code almost mindlessly by total "inversion of control" \- wherever you pass an
object somewhere (making a call), in FP you pass the operation from the callee
to the caller instead.

And I think it's this duality that you observe in practice.

However, I believe there is a practical difference between the two, which
makes FP superior despite being harder to understand initially.

It's much easier to spot that you're doing "no-ops" in FP than in OOP. In OOP,
often you pass the objects unchanged across layers, while in FP, this
manifests as identity functions being used. And it's easier for both human and
compiler to remove these redundant identity functions (through function
specialization and things like fusion etc.).

Also, I believe functional approach allows you to better realize that there
are some algebraic laws governing your problem domain.

It's really kind of like in mathematics, when you come from point-wise
understanding of functions to functional understanding of functions, more
insight is gained.

------
dahart
> What if there is no "complexity trap", just disagreements about how best to
> design programs?

While I think this post asks reasonable questions, and has some healthy
skepticism, the complexity trap is very real, in my experience. After 20 years
of professional software development, I can safely say I've watched literally
tens of millions of dollars wasted over-engineering solutions to problems that
were anywhere from smaller than advertised to did not actually exist.

I also freely admit that I personally tend to deep dive on
cool/elegant/fast/small solutions where my time to achieve the optimal program
is never recouped by running the program.

There absolutely is some under-engineering too, I've done some, and seen some
in the wild. But on the whole my samples are that over-engineering is the
dominant problem. That might not be true for people who hire contractors; from
that point of view, getting less than you think you paid for is probably the
most common experience.

~~~
Raidion
Well, I feel like the environment of the job coupled with the developer causes
over-engineering, rather than true technical concerns.

I'm fairly young for my new role and architecting (from the ground up) some
fairly big systems. I'm really struggling not to over complicate problems and
I think it's really easy to do for a couple reasons.

The selfish architect I'm working very hard not to be would rather have his
work be complex. This builds ego if it works and you can always argue "it's a
complex problem" if it doesn't. He'd rather face the shame of maintaining
software that's overengineered as that's a very low visibility cost. No one
bats an eye at estimates to update an existing system if it's needed. On the
other hand, failure to account for a use case you deemed 'a bit complex for
MVP' is super visible, even if it's a miscommunication between product and
development. This selfish guy doesn't have eyes for business needs, he just
falls in love with solving a problem, when he starts to elaborate on
capabilities that it could have, product manager will just nod and say "oh
yea, that might be nice", so you over-engineer to make sure that pathway is
open, even if the product lady forgot about that possible feature before she
left the meeting. He's also afraid of showing up at a meeting saying we solved
the problem with a boring tweak on an existing implementation and having
someone show him up by asking questions about why he didn't just use a
software platform or language that felt foreign and complex when he read a few
articles about it on reddit.

Idk, felt good to vent some of this stuff, but those are the things I have to
make sure I'm aware of, otherwise I'm just gonna build shit to the ceiling.

~~~
dahart
I agree with all of that. My first reaction is that you’re probably in startup
land where you’re mainly building new things. People do bat an eye at
estimates to update old and large existing systems. It’s the new and small
ones that are easy to update. If you’re even talking about MVPs, you’re
probably not seeing much over-engineering yet. Or, you might have some and not
know it yet, it might take a couple of years before you realize you paid large
opportunity costs solving issues that seemed important. Having to decide
whether to solve an issue before vs after MVP can be hard, but if you know you
need to solve it either way, you’re way ahead of solving something that you
aren’t absolutely sure you’ll need.

A common but not-common-enough (IMO) programming philosophy is to only write
the minimum code necessary to solve problems you actually tangibly have, not
for any problems you think you’ll have, only for problems that absolutely
require solving now and people are screaming for them. Extreme programming and
Agile and lots of other software development frameworks all have variations on
this tenet.

The biggest over-engineering mistakes I’ve seen are when teams decide to
rewrite from scratch a code base that they deem too crufty and too difficult
to maintain and update anymore. Devs make this call far too easily, and fail
to take into account how many things still work and how much effort it took to
get there. I’ve been witness to two very large such rewrites that, many years
later, both companies admitted were colossal mistakes.

------
austincheney
I deliberately try to make things complex, but not more complex than they
actually are, though apparently this is received as a matter of perception. It
commonly boils down to risk or performance versus convenience.

As a senior developer I notice that juniors will sometimes do everything in
their power to over-simplify a given problem. This is more often due to
insecurity than accident or technical ignorance and while their motives are
often unintentional (non-cognitive) the actions are often exceedingly
deliberate (cognitive decisions).

When this occurs the developer isn't changing the problem. They are changing
themselves and their approach to the problem. Unfortunately, this is evidently
reflected in the quality of work. Pointing out this shortcoming can result in
conflict because the offending party's actions, even though often
unintentionally motivated, are deliberate and thus the criticism may be
received as unnecessarily too precise or picky. Again, its all about risk or
performance in the product versus the individual developer's confidence
displayed as a convenience.

~~~
sonnyblarney
That's funny because I have become, and observe the exact opposite.

The notion of trying to make things more complex than they need to be I find
deeply problematic.

Junior engineers often end up devising solutions which are in fact _too
complex_ as they try to over engineer everything.

The more experience I have, the more I accept that code is complexity and cost
and that it should be avoided.

Always take the easy path unless there are very good reasons not to ...
because you'll never know where you need to actually pivot when you get there.

To your point (not more complex than they actually are) - yes, there is
sometimes inherent complexity in the problem space that can't be avoided - but
that doesn't mean the solution actually needs to be complicated. Domain
complexity might possibly be well encapsulated, leaving the rest of the system
fairly straight forward.

~~~
013a
I tend to observe that junior engineers simply misplace the level of
complexity that a system needs in order to be as simple as possible. Meaning,
I've seen errors to the side of being too simple, and errors to the side of
being too complex; the unifying theory here is that its a mis-estimation of
"necessary complexity".

Two examples:

In designing an email templating system, I've seen junior engineers devise
really complex class hierarchies, with super classes that take in type
generics for their super() constructor, three levels deep, resulting in
hundreds of lines of code. When pressed, the reasoning was "there are parts of
the email body we want to be the same and parts that are different, so the
class hierarchies map to those parts that are similar vs different." It turns
out, this service was only sending 3 different email "types" for the
foreseeable future, and the only similarity between them was a copyright
notice at the bottom, a banner at the top, and a body.

But, a counterpoint: For a long while, on some node.js backend API we were
writing, much of the core business logic was implemented as simple functions
across hundreds of files. Worked great when we had four API routes. Now, with
hundreds, its impossible to find anything, because there's no structure,
patterns, or organization. So, we needed someone to step in and introduce
rules and structure in order to make the system more simple, and our job would
have been easier if we'd had the foresight to see that necessary complexity
coming.

~~~
mbrameld
> In designing an email templating system, I've seen junior engineers devise
> really complex class hierarchies, with super classes that take in type
> generics for their super() constructor, three levels deep, resulting in
> hundreds of lines of code. When pressed, the reasoning was "there are parts
> of the email body we want to be the same and parts that are different, so
> the class hierarchies map to those parts that are similar vs different." It
> turns out, this service was only sending 3 different email "types" for the
> foreseeable future, and the only similarity between them was a copyright
> notice at the bottom, a banner at the top, and a body.

Was there a discussion about high-level design of the templating system at all
before the junior started banging out code? This feels more like a failure of
the senior/lead.

> But, a counterpoint: For a long while, on some node.js backend API we were
> writing, much of the core business logic was implemented as simple functions
> across hundreds of files. Worked great when we had four API routes. Now,
> with hundreds, its impossible to find anything, because there's no
> structure, patterns, or organization. So, we needed someone to step in and
> introduce rules and structure in order to make the system more simple, and
> our job would have been easier if we'd had the foresight to see that
> necessary complexity coming.

This feels like a false dichotomy to me. Your system existed in a state
somewhere between between 4 routes and hundreds, didn't it? At the point
something starts being painful is when it should be addressed, imo. That was
probably somewhere in the teens of routes would be my guess. At that point the
system is still small and understandable enough to make a large architectural
change, but it's big enough that you can be reasonably certain you're making
the correct large architectural change.

~~~
013a
> Was there a discussion about high-level design of the templating system at
> all before the junior started banging out code? This feels more like a
> failure of the senior/lead.

There was not. This is a startup I'm referencing; we don't hold long technical
planning sessions for how to design a few hundred lines of code. We'd likely
hold a meeting on the product behind it, but that's not what we're talking
about here.

Does that mean it was a failure of leadership? I'd argue No. I would argue
that it might be a failure in _mentorship_ , which is different, but in all
the startups I've been in, there's one constant: Engineers have MASSIVE
freedom and responsibility to get the product out the door. We don't
micromanage the implementations. That doesn't mean they always turn out great,
and that's where mentorship comes in; teaching how to fish instead of the
seniors doing it for them.

> This feels like a false dichotomy to me. Your system existed in a state
> somewhere between between 4 routes and hundreds, didn't it? At the point
> something starts being painful is when it should be addressed, imo. That was
> probably somewhere in the teens of routes would be my guess. At that point
> the system is still small and understandable enough to make a large
> architectural change, but it's big enough that you can be reasonably certain
> you're making the correct large architectural change.

I think you're right. No one is perfect.

The reality of many startups is that the senior developers are vastly
overworked. I mean, everyone is overworked, but at least in my experience, it
comes back to the fact that the seniors can't micromanage everyone. So at some
point, we were at a dozen routes, and it probably sucked to work in, but its
likely that the seniors reviewed it and "missed the forest for the trees".
Yeah, that code looks great, ship it, next feature, keep growing.

It takes a different, holistic perspective to see that the whole architecture
is slowly getting bad, and often you don't experience that different
perspective working in the weeds on each route. Combine that with the fact
that startups tend to move REALLY fast, and an engineering department four the
size still wouldn't have the capacity to take on all the feature work we want,
let alone the refactoring, and its easy to understand why architecture gets
pushed off.

------
otikik
I can't if it's the typefaces, the interlining, the space between paragraphs
or a combination of those, but that page was so unpleasant to read that I had
to use Firefox's "reader view" to do it. I have no opinion whatsoever on the
the text, but the presentation was so hideous that I thought it was worth
mentioning.

~~~
undershirt
It's the negative line height—you can see by selecting multiple lines of text
that the rows actually overlap each other.

~~~
munchbunny
Spot on. The lines are too long and too scrunched together.

I could feel myself involuntarily squinting to read it.

------
kgwxd
So, we should just "agree to disagree" and stop trying to demonstrate how one
approach might be much better over another? How can anything ever get better?

The Complexity Trap didn't accuse anyone of actively trying to make things
complex, nor did it imply any "moral failings" on anyone's part, it just gave
examples of how common practices can cause accidental complexity. It also
dedicates an entire section to defining "complexity" as used throughout, so
there's no ambiguity there.

~~~
lmm
> So, we should just "agree to disagree" and stop trying to demonstrate how
> one approach might be much better over another? How can anything ever get
> better?

No, we should try to make things better. But framing these choices as
"complexity" doesn't seem to be helpful. The choices are tradeoffs but they're
not a deliberate choice of complexity for the sake of some other value; at
most they're choices between different kinds of complexity, and maybe not even
that much.

> It also dedicates an entire section to defining "complexity" as used
> throughout, so there's no ambiguity there.

And yet I used that same definition but came to opposite conclusions when
applying it to the original author's examples.

~~~
goflyapig
_> deliberate choice of complexity_

I also don't see anything in The Complexity Trap that accuses anyone of that.
I think that's a misreading.

Rather, I think The Complexity Trap argues that many developers have a poor
understanding of what "complexity" means, so they end up increasing it even
when they think they are decreasing it. Specifically, I think the point it
tries to make is that complexity doesn't equate to verbosity, and simplicity
doesn't equate to terseness. That's why it starts by defining complexity in
terms of coupling.

Your article seems to agree that DTOs are more decoupled because you refer to
it as "cargo cult decoupling", yet you still argue it's more complex. So you
_aren 't_ using the same definition.

Having said that, I do agree with you that blind "decoupling" is definitely
not always the answer, and some things _should_ be coupled. When a change in
one thing should _always_ cause a change in the other, purposely coupling
those things in code can _decrease_ complexity.

But I wouldn't say coupling your public API to your internal model by
generating the former from the latter is one of those cases. It's something
that's done for convenience and terseness, at the _expense_ of complexity.
(It's more complex because changes that would otherwise be simple refactorings
could cause breaking changes for consumers of your public API in ways you
would not expect. For example, you won't be able to use automated refactoring
tools safely without carefully thinking through the consequences in your
head.)

Depending on the project, trading complexity for terseness/less boilerplate
might be the right decision. But it should be done consciously.

~~~
lmm
> Your article seems to agree that DTOs are more decoupled because you refer
> to it as "cargo cult decoupling", yet you still argue it's more complex. So
> you aren't using the same definition.

Well I'm using the same definition as the second section of The Complexity
Trap, where it considers introducing an effect algebra to be increasing
complexity.

Whatever tradeoff is made by introducing DTOs is in some sense the same as the
one that's being made by introducing a free monad or tagless final - more
verbosity and less coupling. But The Complexity Trap seems to think that
verbosity is more complex than coupling half the time, and coupling is more
complex than verbosity the other half of the time. So framing either as
"trading complexity for ..." is unhelpful.

------
alexandercrohde
I have to pretty much reject this post wholesale. True the post it's
disagreeing with picked weak examples. But other than that pretty much all of
its overall points were actually very accurate.

The original article was not about json/scala/etc. It was about this:

To summarize, we have to deal with a lot of accidental complexity these days,
for multiple reasons. First of all, we adopt techniques and abstractions
without analying and evaluating their costs and their usefulness in our
specific situation. Moreover, we love solving technological problems.

~~~
lmm
> True the post it's disagreeing with picked weak examples. But other than
> that pretty much all of its overall points were actually very accurate.

That's what I initially thought. But how can the overall points possibly be
right if they lead to exactly the wrong conclusions in most or all of the
specific examples? At best the part you quote is vacuous and unhelpful for
actually making technical decisions.

~~~
alexandercrohde
Just logically, a point can never be disproven with bad examples. Bad examples
may be unpersuasive, may bore the reader, but they don't make a true point
false.

As best I can tell when you call his point "vacuous" you mean you think it's
too abstract to be practical. I disagree.

What I take a away from his article is:

\- Before you build something, ask yourself "Is this REALLY a technical
problem? Or is it better solved non-technically?"

\- What are the costs, especially complexity, of this change? Weigh those
against the benefit.

Seems concrete and useful to me.

~~~
lmm
> Seems concrete and useful to me.

It _sounds_ useful. But Westheide followed this methodology, presumably put
time and effort into it, and yet made completely wrong technical decisions. So
I don't believe the method can possibly be useful; he'd've got better results
by saving his time and flipping a coin. (Put another way, this methodology
doesn't outperform a placebo)

~~~
alexandercrohde
You know that's a bad argument. You can't definitively say "one person tried
to follow a piece of advice and it didn't help one person therefore the advice
is false/wrong/worthless."

I'm sure if you thought about this though that would be pretty clear to you.

~~~
lmm
> You know that's a bad argument. You can't definitively say "one person tried
> to follow a piece of advice and it didn't help one person therefore the
> advice is false/wrong/worthless."

But this isn't just one person trying - this is the example given by the
person giving the advice, so it's presumably the strongest case they can make
in favour of their advice.

------
LandR
Sometimes complexity is needed.

I've worked on too many projects where it's just do whatever is easiest at the
time to get it working ASAP. This works, for a while, but eventually that code
base that no one really put any thinking into around design turns into a tyre
fire.

Maintenance becomes hellish, extending it becomes hellish and error prone.
Finding and resolving bugs become excrutiating.

So when people go for a more complex solution up front, it might not be
complexity for complexities sake, they might actually be able to forsee issues
in the future and want to avoid them.

I wish more software development projects employed front loading the effort,
either in terms of design / architecture / employing some sort of code
analysis / quality control etc or even just thinking. Especially thinking.

If the result of that thinking is more complexity, then it's fine. You're
introducing complexity early, everyone can get used to it because it's going
to make your lives in the future easier.

------
kyleperik
I agree that the idea of "simplicity" can become convoluted. But some of his
specific examples I strongly disagree with. Like others are saying, it comes a
lot from your worldview on programming. Coming from someone who was involved
in an extreme Microsoft Stack (which I definitely get from the vibe of the
writer here, either that or Java?) and gone away from that, I can say
simplicity wins. It really just depends on how simple the given language
allows you to be, and what that looks like.

In my personal opinion the Microsoft Stack really traps you in a box. Not a
bad stack, but you can't really translate the "patterns" you have to use there
into a lot of other stacks.

------
jondubois
No programming approach is perfect but some programming approaches are better
than others. I started programming with a statically typed language for many
years and then I went back and forth between dynamically and statically typed
several times in my professional career. Once you've developed good
programming habbits (which statically typed languages can help you to learn),
ultimately, dynamically typed is better. Dynamically typed languages are
simpler, faster to write, easier to change, easier and faster to test and
debug, focus on raw logic instead of semantics, interact with external
services more easily (JSON is the most popular data interchange format and it
doesn't carry type information), integrate better with unrelated systems (no
type conflicts when integrating different projects).

Functional programming is really nice for some things but ultimately, you need
to store state somewhere and often you don't want to store all the data in
your entire system inside a single monolothic store or database - Often, you
want data to be close to the logic which operates on it; having a global data
store is often just as bad as using global variable names in your application;
it can lead to conflicts (forces you to think about data in a system-wide way;
not accounting for data from external systems) and makes it hard to track
where the data is used within the system.

~~~
rienbdj
I came to the opposite conclusion. Working on a dynamically typed project
feels slippery... whenever you make a change it is difficult to know what will
end up broken. I agree that deserialization can be a pain up front, but for
the long term stability and assurances it is worth it.

------
pcunite
I heard somewhere, "People are not against you. They are just for themselves."

------
just_myles
What a read. I agree, often times we overlook the obvious solution and tend to
go for a more complex one. The approach should always be simple. I don't know
why anyone would ever think otherwise.

If the issue is complex in nature, you can still start with a simple solution
before you dig into the weeds. I swear, sometimes people just love to work
extra.

------
james_s_tayler
Software is art, fashion and politics.

~~~
agsdfgsd
Except not the first one.

~~~
james_s_tayler
Well you can implement the same program in endless different ways. Particular
styles develop. Each piece of software is unique.

You're engineering with an artform that's why you see so much variation among
the patterns.

Every portrait might be recognizable as a portrait, but every portrait is
unique in its details.

~~~
agsdfgsd
Different ways to do things is not art. Patterns emerging from those different
ways is not art. Art is for emotional purposes:

"the expression or application of human creative skill and imagination,
typically in a visual form such as painting or sculpture, producing works to
be appreciated primarily for their beauty or emotional power."

Software developers have a tendency to try to claim artist status because what
they do is almost entirely meaningless and a waste of time. The exchange of
time for money is too transparent so they are unfulfilled and try to imbue
their work with meaning. If you want to make art, do it, it can be a hobby.
Yet another useless website created to shove more ads in people's faces is not
art.

~~~
Pete_D
I assumed OP was using a different definition of art
([https://en.wiktionary.org/wiki/art#Noun](https://en.wiktionary.org/wiki/art#Noun)):

> 2\. ( _countable_ ) Skillful creative activity, usually with an aesthetic
> focus.

> _She 's mastered the art of programming._

..

> 7\. ( _countable_ ) Skill that is attained by study, practice, or
> observation.

If that doesn't convince you, compare with such phrases as "The Art of War",
"artisan bread", or "liberal arts" (which includes topics like philosophy).

------
barberousse
This is a particularly thorny issue as a Junior Developer. There's the issue
of the Junior reaching beyond their britches, but there's also the issue of
Seniors being set in there ways.

~~~
brabara
As mid level developers, how can we resolve this impasse?

~~~
dwaltrip
There is no ultimate solution. Just continual efforts to make things better,
gain deeper understanding, remove unnecessary complications, and improve
overly simplistic solutions.

If you were simply making a joke, forgive me =)

~~~
brabara
No joke at all, sadly I see this day to day.

------
Myrmornis
Judging by the initial half-second of chaos on page load there's certainly
something complex about the javascript this person is using to communicate
these words.

~~~
lmm
I used to have the content hidden before the javascript styled it, but people
on this very site complained that they couldn't read my pages without
javascript enabled.

~~~
Myrmornis
Cool, that sounds annoying :) I didn't mean to be issuing criticism on a
trivial side-issue. I kind of thought no-javascript pedants stopped being
listened to in 2014.

------
coldtea
> _Having business requirements that interleave pure operations with effectful
> ones - "if the request exceeds one of our free account limits then check the
> user's subscription is still active in this external service" \- is normal,
> like it or not._

Isn't that what the "imperative shell" is about?

------
justicezyx
This article reads into the replies article and hand picked a few points.

While actually the article agree on the article it referred to. But the
wording has been in a way that is argumentative, which is rather immature
imho.

------
avip
Couldn't read because of the terrible font but I'm sure I disagree with all he
says.

~~~
anonytrary
I read your comment expecting to see something like Papyrus, but it was just
Georgia and Times New Roman. What's the fuss about?

------
jeklj
Until there is some reliable way of comparing the complexity of two things,
when people say something is “complex” what they usually mean is that they
don’t like it or it’s unfamiliar.

Or better yet, your complexity is incidental, mine is essential. I was
_forced_ to make it complex, you did it because you’re not trying hard enough!

As Rich Hickey’s dictionary reminds us, to complect is to entwine together
things better left separate. If you aren’t using the word in this sense, if
you aren’t identifying the specific concepts which are complected but should
be separated, you’re using fancy words to say you don’t like something. I’ve
noticed we tend to do that, a lot.

I’m very wary of doing this in my own thinking, personally. It’s okay to just
not like something, and it’s more honest just to say so than to use objective-
sounding words in an attempt make it about something other than one’s own
taste.

------
brabara
As someone who has read Moby Dick front to back I can agree with this
argument. I had a colleague once, really bright engineer but not as steadfast
as I was at the time. I suggested he read this amazing novel and he instead
opted for the book on tape. During a long drive he almost died from boredom.
Literally! He almost fell asleep at the wheel. While he disagreed with me that
manually reading the book was the optimal approach he was not trying to make
things more complex. He was merely trying to take the easy way out. This grave
mistake almost cost him his life. Consider this tale next time you are
thinking about not putting in some work!

~~~
googlemike
This comment feels like a markov chain wrote it. Do you really find parallels
between this anecdote and reality? What if we presented an anecdote of the
opposite to you, would you change your worldview entirely? If not, why should
anyone who reads this?

~~~
sonnyblarney
+100 points for that analogy. "Your prose reads like a Markov Chain". That is
Gold. I'm putting that on a T-Shirt.

~~~
brabara
Could you provide a link without a referral?

