Hacker News Reader

Comment by freyrs3 | Hacker News Reader

Reducing software development practices down to these cute catchphrases is a bit disingenuous. If you're writing throwaway code for a client with loose constraints and a tight deadline you'll write code differently then you would when you expect to maintain a long term relationship with a client who expects a high degree of correctness. I'm tired of these trite articles espousing some cute mantra holds as if it's some universal property of software development.

View on HN

The worse thing is that he's saying "you shouldn't spend extra time to do the right thing", and then tries to justify that by giving examples of people doing the wrong thing. Nobody is calling spending weeks writing a caching layer for a 20-row database "elegant" or "best practice". That's a complete straw man.

I don't know. The whole ecosystem we live in (YC) seems to be about, "Your idea may be good, but mine exists."

Basically, the same thing as he's saying.

I felt the same about the YC ecosystem, which is why I submitted this.

Sort of. That just means they endorse an Agile approach - ship bare minimum features early, and continuously improve. Not ship bare minimum features early, and who cares about how its designed. The whole over-engineering argument is a straw man, because over-engineering is just as bad as under-engineering. Neither one is desirable in professionally written software.

A lot of the time once you have a good understanding of some of some more mature practices it doesn't take any longer to do the 'right' thing.

"Nobody is calling spending weeks writing a caching layer for a 20-row database "elegant" or "best practice"

I don't disagree with your main points, but you might be surprised to hear some things that people will say and unnecessary optimizations they'll attempt...

> Nobody is calling spending weeks writing a caching layer for a 20-row database "elegant" or "best practice". That's a complete straw man.

Have you used any Java API? That's exactly the feeling I get from using them.

The people who make the most noise about elegance and best practices generally dislike Java for precisely that reason.

I use plenty of Java APIs. It's a vast ecosystem of code, generalising across all Java libraries ever is silly.

I was involved in a software development project last year, in which the entire remote development team of 20 people got fired, because the software architect implemented a bunch of best practices, design patterns and state-of-the-art frameworks, without any thought as to how this would impact development time. The problem was that he was the only one who was familiar with most of this stuff, so there was a very steep learning curve for the rest of the team, who one by one either dropped out or became totally unproductive. After 18 months in which he burnt his way through the budget, with very little to show the client by way of results, the project was drastically scaled back. So this is not just about straw men. People like this really do exist.

Things like best practices become more important the larger the team. Are you suggesting the project would have been more successful if they had been less concerned about code organization and unit testing (or whatever you mean by "best practices")?

The problem was not the use of best practices per se, but the uncritical use of these practices. For example, it's good to use design patterns, but not every pattern is appropriate to every situation. We got to a point where it might take a full day to make a change to a table, and then make the corresponding changes to all the various repositories and entities. Similarly, it's good to use the latest technologies, but using beta versions of unpublished frameworks was a bit over the top, both because documentation was scarce and because they were still buggy.

Exactly. Specially with the chosen title.

Almost all similar articles I read, are used as some kind of self justification to writing bad code and leaving it there forever.

If you believe the software will fail (won't ever be changed/grow), do whatever you want with it. If you think it'll succeed, stack too many dirty hacks together and you're gonna pay for it later with tons of interest.

Main problem is, too many times this goes "unnoticed", people just take longer and longer to do the same things, but people stay oblivious to the real causes of that technical debt.

> Almost all similar articles I read, are used as some kind of self justification

Nerds (of which I am one) tend to be really good at rationalization. These articles serve as a sort of catharsis ("I probably could have done better, but I was really just moving fast and breaking things!"). Other times, these articles are written as a means of projecting identity (e.g. "I reject enterprise-y nonsense by refusing to doing any sort of analysis or design!")

Both are exceedingly poor motives.

Nerds ( also one myself ) tend to suffer from the over-generalization fallacy. Whereby they think that their local experience generalizes to a much larger scope. For instance, If you read most of HN programming articles with the prefix "when writing code for a web startup" they make sense, if drop that prefix they stop making sense. It also helps to keep in mind that advice that holds in the startup world can be quite toxic when applied elsewhere in the industry.

Definitely. I disregard most 'engineering' advice I read in HN threads for exactly this reason. Most of it falls into the "I don't believe it's an issue in my 1.5k LOC app, so it must not be real!"

A while back I tried to add some clarity to the discussion.

http://deliberate-software.com/quality-is-future-speed/

Meta comment: The article: (a) covers enough relevant topics (b) using rather ambiguous terminology (c) while offering sharp opinions (d) about a world of pain (e) that we all experience (f) but can never be solved in general

This is not a bad formula for crafting a blog post that you want to get picked up via HN. It is also a great way to start a discussion that will never end.

>Reducing software development practices down to these cute catchphrases is a bit disingenuous.

Its a bit like Scientology, but without the crazy.

Oh no, wait .. there's plenty of crazy.

Same idea, you reduce arguments down to these repeated definitive-sounding cliches that are held sacrosanct and impenetrable to dissent.

Reply on news.ycombinator.com