Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

People who disagree aren't trying to make things complex

m50d.github.io

Post reply on HN
Print view View original

71–80 of 162 posts

Re: People who disagree aren't trying to make things complex

#71

Post by flukus »

klodolph wrote: post #64
dmreedy wrote: post #14

Earlier quoted context omitted.

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 standar…

> 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…

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

Re: People who disagree aren't trying to make things complex

#72

Post by 0xdeadbeefbabe »

genericone wrote: post #41
stevenjohns wrote: post #35

Earlier quoted context omitted.

> 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. At a previous company I worked for I proposed a solution which was considered to be too "complex" by the VP R&D. So he and another "Senior" turned around and rewrote it into something mo…

Looks like the two of you have a different worldview about what 'simplicity' means.

It really nice of you to notice. Some crusaders still think it's about complex vs simple.

Re: People who disagree aren't trying to make things complex

#74

Post by james_s_tayler »

0xdeadbeefbabe wrote: post #73
james_s_tayler wrote: post #21

Software is art, fashion and politics.

No it's about right and wrong. That's why software is fundamentally binary.

That's what people make it about. It's classic misdirection.

You know, the 20th century American sci-fi writer Robert A. Heinlein in his 1953 novel Assignment In Eternity wrote "man is not a rational animal; he is a rationalizing animal." And Aristotle said that man was a political animal. I deduce from that that "man is not a political animal; he is a politicizing animal."

That's why we get arguments and debates around there subjects and they become so heated. The truth of the matter is the only way it's possible to compute the answer to any given programming debate is to implement all suggestions in parallel universes and see which one doesn't cause World Was III inadvertently. You can't compute the answer, so you go off hueristics of what's a) what's popular in the wider community (fashion) b) what's popular in your local community (politics) and c) what's popular with you (art).

I need to write a full article on this viewpoint at some stage.

Re: People who disagree aren't trying to make things complex

#76

Post by quickthrower2 »

0xdeadbeefbabe wrote: post #73
james_s_tayler wrote: post #21

Software is art, fashion and politics.

No it's about right and wrong. That's why software is fundamentally binary.

Who decides if something is right or wrong? Have you never heard a developer debating "is this a bug? is this a feature?"

Re: People who disagree aren't trying to make things complex

#77

Post by throwaway413 »

flukus wrote: post #71
klodolph wrote: post #64

Earlier quoted context omitted.

> 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…

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

Hey now, CoffeeScript is real engineering ok?

Re: People who disagree aren't trying to make things complex

#78

Post by dwaltrip »

brabara wrote: post #49
barberousse wrote: post #5

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.

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

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 =)

Re: People who disagree aren't trying to make things complex

#79

Post by skybrian »

klodolph wrote: post #65
yason wrote: post #44

Earlier quoted context omitted.

I think programming has more trade-offs to choose from, and thus more freedoms. You can make a program slow, fast, small, large, limited, comprehensive, quickly written for a specific case or carefully designed for the generic case, or anything else at the expense of something else. Building a bridge doesn't have much of that: the bridge must withstand loads from the traffic, loads from the elements, material wear ac…

The reason a bridge is so constrained is because we have scaled the difficulty of the problem upwards until it is near the limits of our budget and ability. Many software projects are profitable without being anywhere near physical limits. Other software projects are not, if you are working for an HFT, then you're counting microseconds and measure distances by how long it takes light to travel. If you're storing 10^1…

For a more realistic comparison, you could look at the relationship between structural engineering and architecture. A lot of engineering goes into structures that are built a certain way just for looks, even though it's more expensive and often less functional.

This even affects bridges. The new eastern span of the bay bridge didn't have to have a tower at all. They chose the more expensive option because it looks better.

Re: People who disagree aren't trying to make things complex

#80

Post by kokokokoko »

ilaksh wrote: post #3

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 progr…

These are great points and I wanted to add a couple more I've found over the years.

Software development often has an almost infinite number of ways to accomplish the same task.

Maintainability is as much, if not more, about correctly predicting the future uses and requirements of the software as it is about the initial coding practices and design patterns.

Working on older systems that are being used in ways that they were not originally intended is often uncomfortable for a developer. All but the most junior developers tend to have some painful memories of battling legacy software.

These add up to a situation where it is incredibly difficult and vague to determine the correct path. Both because there are so many ways to accomplish the task and because there are so many unknown future contingencies that ultimately determine how maintainable the software will be. Combine that with the painful memories most developers have from nightmare projects and you have yourself a recipe for emotional disagreements all around.

The grand irony is that, very often, once a developer becomes fully aware of this concept, they lose that internal fire and vigilance required to constantly seek out better ways to solve problems and their skills wane.

Post reply on HN