"Your code may be elegant, by mine fing works."
Really, prove it. Oh wait, writing tests is 'over-engineering' and "Best Practice", you don't do that. Do you use WinZip every night rather than use an SCM? yes? your a f*king idiot.
Your code may be elegant, but mine works
161–170 of 174 posts
Re: Your code may be elegant, but mine works
#162My code might not be that elegant, but it's maintainable . I've followed "hey, it works" developers who knocked out functionality quickly. Their by-product was Lovecraftian code.
Yeah, my team has inherited similar code from one particular Boy Wonder. One example was a service that imported JSON from third parties - it was unit tested, but the architecture was so poorly testable that it had mocked dependencies three levels deep. We also picked up a home-rolled reporting tool that was an instant injection of significant technical debt.
Re: Your code may be elegant, but mine works
#163Earlier quoted context omitted.
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…
> You can spot these developers by a complex class hierarchy that does absolutely nothing
Oh yes, most definitely. Why have one class when you can have three classes that provide the same functionality?
Re: Your code may be elegant, but mine works
#164The 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…
ditto. Phony concern for technical debt is the perfect cover that many developers use to further their own ideology instead of simply focusing on getting things done.
Technical debt can be a very real issue though. I always strive to highlight the 'interest' we are paying on our technical debt to our product owners, so that they understand what deferring necessary work is costing them.
Re: Your code may be elegant, but mine works
#165This is a great excuse to write terrible code that "works" until it goes out and breaks. Then it doesn't work because you saved a little bit of time by cutting corners. What is the cost of it breaking? $0? $1,000? $10,000? What is the cost to fix the broken code? What is the cost to maintain it? How much developer time do you waste down the line because they have to fix the "working" code? I say these things because…
>How much developer time do you waste down the line because they have to fix the "working" code? That is absolutely spot on. One of the hardest thing is explaining to management that the code your co-worker wrote in a "flash" three years ago is still eating up developer time today. We have a few ill-conceived or badly written systems that seems to eat up time and constantly interfere with new projects. The problems a…
O-TI makes money fixing broken shit.
Re: Your code may be elegant, but mine works
#166Earlier quoted context omitted.
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.
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.
Re: Your code may be elegant, but mine works
#167I managed to read the article before it went down, it was a pretty good read. Hopefully it comes back up soon. Anyway it makes a good point that business objectives come before "best practices" which I agree with, but you need to be careful when cutting corners that you don't actually sabotage your business objectives. The real discussion is actually on a risk level: if I cut corner X, I can potentially make revenue…
I like seeing this probabilistically! That said, I think the operative decision is "should I cut the corner?". If so, you should also factor in the p( ___ | not cut corner ) probabilities. So, you should cut the corner if the benefits exceed the costs. Written out: p(~P|C) * b(~P) - p(P|C) * c(P) > p(~P|~C) * b(~P) - p(P|~C) * c(P) Symbols: p = probability; b = benefits ($); c = costs ($); P = problems; ~P = no probl…
Definitely, thanks for adding in those terms. I kept it simpl(er) and left out the extra terms because I think that those two terms (benefit from cutting the corner vs loss of not cutting the corner) are the major factors when making the decision as they can have big effects on the business itself, while the other terms are just shifting around a bit of extra money/time. Maybe. It would depend on the corner.
Everyone just thumb sucks it in the end anyway - I'll just embed this domain name in the distributed binary, nobody will ever steal our domain name! Technically someone at this point should pull up the statistics for stolen domain names to get an estimate for the probability, and work out how much it would cost to set up a system to pull a correct domain name from a backup, and then work out the cost to redistribute all the binaries to end users whose software won't be working for some time. I doubt anybody has ever done that particular calculation.
Re: Your code may be elegant, but mine works
#168Earlier quoted context omitted.
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…
Sounds more like Cargo Cult programming than an attempt at elegance.
Re: Your code may be elegant, but mine works
#169Earlier quoted context omitted.
> 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-bra…
Exactly. I claim that someone's personal opinion on the author's coding skills IS irrelevant. We should concentrate on his _arguments_, not dismiss his arguments based on here-say about what he has or hasn't done.
He doesn't argue that HE writes good code, he discusses general topics.
Re: Your code may be elegant, but mine works
#170Earlier quoted context omitted.
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 stee…
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")?