Live data from Hacker News

Your code may be elegant, but mine works

omniti.com

131–140 of 174 posts

Re: Your code may be elegant, but mine works

#131

The main reason that I agree with this is that developers are, as a group, the boy who cried wolf. It's not that technical debt doesn't matter or code quality doesn't matter but so many developers complain about technical debt and code quality when their concern is irrelevant or flat-out wrong that it's difficult to distinguish a legitimate concern from complete BS. Developers very often use technical debt or doing t…

If it is elegant then it won't have tight coupling everywhere. Presumably by "elegant" you really mean inelegant.

Hence the quotes. What I find interesting is that there's a class of developers for whom their quest for elegance results in the exact opposite of elegance. You can spot these developers by a complex class hierarchy that does absolutely nothing, a complex configuration management system that allows you configure everything at runtime except the settings you want to change, which requires recompile and over-engineered replication of the underlying platform or a library and an occasional commit or two that rewrites perfectly good working code to adhere to their idea of what's good, while introducing bugs and incompatibility.

This kind of behavior seems malicious but I think it's more often the result of wishful thinking. A lot of these come as a result of imitating good design without understanding the context that makes those choices good or even necessary.

Re: Your code may be elegant, but mine works

#133

Earlier quoted context omitted.

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

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

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!"

Re: Your code may be elegant, but mine works

#134

I used to work at OmniTI. The real irony of this article is that it was written by a guy who's (in)famous for his indecipherable Perl one-liners. I think that's about all that needs to be said.

> I think that's about all that needs to be said. Yeah, and that's like a perfect definition for "ad hominem" argument.

You people really need to work on your fallacies. Quoting from the Wikipedia definition of Ad hominem:

"[I]n which a claim or argument is rejected on the basis of some irrelevant fact about the author [...]"

Leon is a really nice, super funny guy, but the fact that no one can maintain the code he writes is highly relevant to the subject of the article. In summary, http://lwtc247.files.wordpress.com/2010/06/get-a-brain-moran...

Re: Your code may be elegant, but mine works

#136
post #8

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

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

Re: Your code may be elegant, but mine works

#137

Something important is almost never mentioned in all the literature about programming and software development, and as a result we sometimes misunderstand each other. You're a software developer. Me too. But we may not have the same goals and requirements. In fact there are several different worlds of software development, and different rules apply to different worlds. http://www.joelonsoftware.com/articles/FiveWorld…

Similarly, paraphrasing (as I don't have my copy right here with me),

Not all software projects are the same, no more than all construction projects are the same. You can quickly nail a dog house together with only vague planning and minimal craftsmanship. But if you want to build a house for people, you have to plan more, pay more attention to what you're doing, and make sure the result meets the local codes. If you want to build a skyscraper, you have to put even more work into planning, robust engineering, and code-meeting than you do with a house.

http://www.amazon.com/Software-Architecture-Primer-John-Reek...

I've worked on software for iPhones and on software for jumbo jets. The two activities almost aren't even the same thing. Drawing on other life experiences, I might liken it to jazz improvisation vs. classical performance, or to mobile phone snapshots vs. professional portraiture. Overlapping, yet different enough that methods which work for one do not necessarily make sense for the other.

Re: Your code may be elegant, but mine works

#138
post #137

Something important is almost never mentioned in all the literature about programming and software development, and as a result we sometimes misunderstand each other. You're a software developer. Me too. But we may not have the same goals and requirements. In fact there are several different worlds of software development, and different rules apply to different worlds. http://www.joelonsoftware.com/articles/FiveWorld…

Similarly, paraphrasing (as I don't have my copy right here with me), Not all software projects are the same, no more than all construction projects are the same. You can quickly nail a dog house together with only vague planning and minimal craftsmanship. But if you want to build a house for people, you have to plan more, pay more attention to what you're doing, and make sure the result meets the local codes. If you…

Exactly. But it doesn't degeneralize to "Everything is so different that rules of thumb are not useful guidelines," but rather that within a particular "genre" or "world," there are sensible defaults that don't work in other genres or worlds.

Re: Your code may be elegant, but mine works

#139
post #57

Great article. Note that much of the attitude comes from a belief that what is good for the company is ultimately good for the engineer. However, I'll suggest that's not always the case. Take for example one of the OA's reflections: " Technical debt should be weighted against the actual ROI, because in many cases it is more cost effective to launch early. This way, though you may be accruing technical debt, you are a…

> Unfortunately, dependant upon your company, that last part may never happen and if I were to frequently experience that at a company, well, you better believe I would rather quit and if I couldn't quit I still would rather put my foot down and pump the tech debt argument for all it's worth, otherwise, in the longer term, working there would be a living hell. Wish I could upvote you twice. My company has so much tec…

Perhaps the concept of Technical Bankruptcy should be introduced.

Re: Your code may be elegant, but mine works

#140
Yes yes, done is better than perfect.

However, it helps tremendously for imperfect code to exist in a disciplined higher-level organization. In particular for OOP, this means interface and package/assembly responsibilities should be clearly-defined and leak-free. To me, this is the minimum ideal--it may never be definitively achieved, but one should aim for no less. Then, all manner of code abominations can be hidden and compartmentalized. Various components can be improved and cleaned at will, without rippling out destructively throughout the codebase.

This means some shortcuts are not allowed, and time to delivery will increase slightly. But those are the shortcuts that create spaghetti-code and tend by far to incur the greatest debt. So I see this simple minimum bound as a good 80/20 tradeoff for maintainability.

Post reply on HN