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

Your code may be elegant, but mine works

omniti.com

Post reply on HN
Print view View original

151–160 of 174 posts

Re: Your code may be elegant, but mine works

#151

Post by dj-wonk »

rpm33 wrote: post #88

The higher order bit remains writing high quality code under pressure that works. High quality encompasses well tested, adherence to abstractions, maintainable and readable.

Right. One key question is this: what does "high quality" mean?

If your product is a first iteration on a web application, user interaction may be a key part to quality while database tuning may not.

If your product is a data analytics service, database tuning may actually be very important while the user interaction may be less so.

Re: Your code may be elegant, but mine works

#152

Post by lostcolony »

bnegreve wrote: post #93
lostcolony wrote: post #31

I live by a comment Joe Armstrong made on this (from Erlang and OTP in Action): "Make it work, then make it beautiful, then if you really, really have to, make it fast." (The quote continues "90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!")

> 90 percent of the time, if you make it beautiful, it will already be fast. In fact, I disagree with this. The reason is that "elegant" usually means "decoupled" whereas many optimizations actually consists in "recoupling" to take advantage of special cases or to share resources among various decoupled objects. Designing software to be fast and elegant is actually quite challenging problem. Of course, that makes it…

I would argue that the reason you are choosing to recouple things, is because you fall into that 10%. Most problems can and should be solved first correctly, second elegantly, and you will find at that stage it is "fast enough". It's so rare to not find that to be true, overall (i.e., some industries, such as high speed trading, there is no such thing as fast enough, but they're writing Interestingly, too, you indicate "recoupling". That is, to couple again. Meaning for you to even be in this situation, realizing what you need to do, you had to first make it elegant. Otherwise you'd be optimizing...what, exactly? You have no metric.

Re: Your code may be elegant, but mine works

#153

Post by vitd »

This whole article reminds me of todays article from "The Daily WTF":

" rel="nofollow">http://thedailywtf.com/Articles/User-Rejection-Testing.aspx>

"There are only two options here: either you did your job and the application is correct, or you’re an incompetent and it’s wrong."

Re: Your code may be elegant, but mine works

#154

Post by jarrett »

Edmond wrote: post #107
jarrett wrote: post #96

Earlier quoted context omitted.

This is a problem, and I've long mused over possible solutions. Every time I think about it, I come to the conclusion that the solution isn't a new approach to software engineering, a new language that blows away every paradigm, some abstraction that promises to make app development simple, or any other silver bullet. Indeed, the only "solution" I see is a solution in just the loosest sense. Namely: We continue incre…

A good tool does not need to throwaway existing frameworks or paradigms in order to deliver. I am a firm believer in using what's already proven. >The complexity of the tools we use is a result of their great flexibility and power. This may see like a strength but it is actually a massive weakness. Existing IDEs attempt to be all things to all people and as a result are not actually delivering the best that they coul…

I looked at Crudzilla. (Is that the product you're referring to?) I don't really have the time to test-run a new framework right now. Perhaps you could give a quick overview of how you're solving the key problem I identified above? To recap, my argument is: The web stack must be flexible and powerful, because nobody's abstraction layer can anticipate the weird, idiosyncratic little needs of most real-world projects. Thus, the flexibility and power of the dominant tools, like Rails and Django, can't be sacrificed in the name of simplicity. Or if you do make that sacrifice, your tool will only be useful to the tiny subset of applications that fit into your narrow definition of how an app works or what it does.

Re: Your code may be elegant, but mine works

#155

Post by dj-wonk »

freyrs3 wrote: 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…

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.

Re: Your code may be elegant, but mine works

#156

Post by jarrett »

jmccree wrote: post #122
jarrett wrote: post #103

Earlier quoted context omitted.

Exactly. The author cites a Christmas promotion as an example. Yes, those types of projects exist, but in my experience, they're a tiny minority. Almost every deadline I've ever faced was set artificially. The developers estimate how long the project will take, they negotiate with management, and one or more deadlines are established. Often these deadlines are missed (not due to the programmers, BTW), and there's no…

You are lucky if deadlines with actual penalties have been a "tiny minority" of your experiences. The problem I experienced too much at some companies is "management" making artificial deadlines become real deadlines. VP of X sees feature set for delivery on Friday, sets up demo for potential client on Friday. Now everyone is in crunch mode or the company suffers when client can't see the feature. Or CxO drops in and…

Ouch! Yes, that can happen, and I'd argue it's pathological. Let me rephrase that series of events as follows:

1. Artificial deadline is set. 2. Artificial deadline is unnecessarily converted into crucial deadline. 3. Code quality suffers, saddling the company with technical debt that costs real money and real opportunities later.

> many of the deadlines are baked into the contracts as deliverables

Oh absolutely. I'm a consultant too, and I do that all the time. I set my contractual deadlines such that I don't have to sacrifice the codebase. Granted, there are exceptions to every rule, and I'm not going to claim I've never, ever accrued technical debt due to a deadline. But I wouldn't make it a philosophy, which the article seems to be doing.

Re: Your code may be elegant, but mine works

#157

Post by ryanjshaw »

viraptor wrote: post #38

He presents so many false choices it's not even funny. (also we're adults, either you really want to fucking write it, or don't - stars don't help) > If the client needs a Christmas promotion, and you deliver the best product in the history of promotions -- on December 29th -- it's worthless. There's almost always another option - if it's going to be a complete mess that will give everyone additional work in January,…

Well this is a developer working on Christmas promotions. It's a bit difficult to take him seriously. Let's see how he copes on a smallish 20,000+ person hour project scope with a 5 year+ expected maintenance lifetime and then revisit the discussion.

Re: Your code may be elegant, but mine works

#158

Post by dj-wonk »

RyanZAG wrote: post #7

I 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 problems; C = cutting corner; ~C = not cutting corner.

Rearranging to:

    p(~P|C) * b(~P) - p(~P|~C) * b(~P)
    >
    p(P|C) * c(P) - p(P|~C) * c(P)
Then you get a simpler form:

    b(~P) * (p(~P|C) - p(~P|~C))
    >
    c(P) * (p(P|C) - p(P|~C))
An amazing fortune awaits any person who can simply evaluate this inequality in real-world situations.

It is also useful to know when the cost of gathering the information to evaluate the expression is not worth the potential benefit!

Re: Your code may be elegant, but mine works

#159

Post by dj-wonk »

jarrett wrote: post #96
Edmond wrote: post #59

Earlier quoted context omitted.

> But if you're in a time-sensitive situation and your code will only be used for a brief period of time, your business needs are probably very different than a code-and-maintain-forever situation (e.g. a SaaS offering). I think this captures the central problem in our current software development state of affairs. Because as developers we are stuck with primitive tools that make doing even trivial stuff time consumi…

This is a problem, and I've long mused over possible solutions. Every time I think about it, I come to the conclusion that the solution isn't a new approach to software engineering, a new language that blows away every paradigm, some abstraction that promises to make app development simple, or any other silver bullet. Indeed, the only "solution" I see is a solution in just the loosest sense. Namely: We continue incre…

I see intrinsic informational limitations. Software developers and managers learn, but they also forget. Also, technologies change, so knowledge "rusts" over time. So the rational ability to make information-based trade-offs is dynamic. Now, think about competition and you can see why this gets complex. I wouldn't be surprised if there is a system dynamics paper on this phenomena.

Re: Your code may be elegant, but mine works

#160

Post by EdwardDiego »

wtbob wrote: post #117
danellis wrote: post #33

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

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

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