Comment by eternalban | Hacker News Reader

Comment by eternalban | Hacker News Reader

Parent Full thread

Anyone who has ventured into software from an engineering discipline takes it for granted that redundancy is necessary for reliable and robust systems. Another aspect of the engineering mindset that is relevant is the acceptance of burden of rigor in service of the end user.

In ('haute couture') software, the matter is up-ended. It is the 'comfort' of the developer that is a key consideration and not the reliability of the product. They don't wish to be "bored" with "boring" "boiler plate", etc.

I think the problem boils down to this: given the infancy of this field and the (still) primitive tooling available to support the mind-work, the field requires and attracts high percentile minds who are then tasked with building (again and again) what is in most cases glorified book keeping or plumbing systems. Naturally an outlet is required for self expression (which is a very basic need for high power minds) and that increasingly translates to need for 'bling' (thus the periodic migrations from the last "cool" stack to the new thing), and aesthetic 'elegance'.

I think that you are making a mistake in equating redundancy in engineering with redundancy in programming.

The point of redundancy in engineering is having multiple parts so that if one of them fails, the others can take over its burden. In programming this might be analagous to having multiple workers serving a queue of requests, for example.

The point of conciseness in programming is to provide consistency. You have a standard part that you can use the same way in many places. In engineering, it would be comparable to writing "use #7 widget" instead of drawing out the complete design for the widget in every place that you use it.

> In ('haute couture') software, the matter is up-ended. It is the 'comfort' of the developer that is a key consideration and not the reliability of the product. They don't wish to be "bored" with "boring" "boiler plate", etc.

The thing is, if the developer and/or code reviewer get bored reading boiler plate, they will pay less attention to the code, and will likely miss important things.

Have you met autoformat? Spend 5 minutes setting up a decent IDE to do this for you.

What? How does an IDE prevent a code reviewer from having to read through boilerplate?

There is a palpable disdain for any concept of discipline or engineering in this age of Lean. YAGNI, they cry! Just ship! To feed this culture of shipping-before-thinking, we're inundated with an endless stream of magical frameworks that will do nearly everything for us if we just trust them completely.

I agree with a chunk of this, especially the dislike for magical frameworks, but you're wrong to pick on Lean and YAGNI there.

YAGNI (You Ain't Gonna Need It) in specific comes from Extreme Programming, which is big on engineering discipline. E.g., its inclusion of Test-Driven Development and Pair Programming as practices. YAGNI isn't used there to reduce quality; it's used to reduce product complexity by only building features that are demonstrably necessary. Which, in my experience, helps with quality.

As to Lean, it's rooted in Lean Manufacturing, which comes from Toyota. An engineering-driven company, they used Lean techniques to reach quality levels way higher than competing car manufacturers, which gave them an enormous competitive advantage.

If people are using those terms to justify shipping crap, then they're doing it wrong.

>YAGNI (You Ain't Gonna Need It) in specific comes from Extreme Programming, which is big on engineering discipline

How is extreme programming even remotely related to engineering discipline? It is a bunch of randomly tossed together practices with no proven value or efficacy, pitched by people who were incapable of doing the job themselves, to teach other people how to do the job. YAGNI is controversial at best, and often creates far bigger problems that what it was intended to solve. And that is when it is combined with the rest of the rituals it was intended to work with. On its own it isn't even recommended by the people who made it up.

>As to Lean, it's rooted in Lean Manufacturing

The name is anyways, but that seems to be about it. Lean manufacturing was about eliminating things that don't add value for the customer. The lean fad in software development seems to be most often applied by people who can't even tell you who their customer might be, much less what adds value for them.

>If people are using those terms to justify shipping crap, then they're doing it wrong

If processes rarely work and any failure is dismissed as "you're doing it wrong", then your processes are worthless. This is "any failure can be attributed to you not following our religion correctly" thing is one of the major things that killed XP.

Regarding Extreme Programming: works for me. Sorry you couldn't make it work for you.

Regarding the Lean fad, yes, all fads in software are shallow and foolish. I'm not interested in taking responsibility for shallow idiots, so if you'd like to yell at somebody about that, seek elsewhere.

Reply on news.ycombinator.com