Live data from Hacker News

Your code may be elegant, but mine works

omniti.com

51–60 of 174 posts

Re: Your code may be elegant, but mine works

#51
Your code may f'ing work, but my code works and is elegant. So what if my code takes a little bit longer to write? From a technical perspective, it's easy to see how this is good. Spending a little bit of time to make your code better will save you hours if not days in the long run.

I also have to question whether this is really good from a business perspective. "First mover advantage" really is overrated. Rather than cutting corners to launch your product a couple of days sooner, perhaps you should be focusing on the long term.

Granted, there are all kinds of caveats we can think of. For example, very early startups don't have the option to focus on the long term and just need to ship something. But even then, putting in a little bit of time up front to polish your code will greatly help your velocity for your next couple of features. You are planning on having more features past the first couple, right?

Re: Your code may be elegant, but mine works

#52
post #28

There's basically just one golden rule: a programmer tries to minimize his total amount of work (because then s/he has more work capability available for any of the more interesting stuff). This applies to throwaway code vs. maintainable code as well. In programmer's head there's a running judgement ongoing while crafting something new: there are constant decisions on if cheating with quick'n'dirty hacks is the way o…

There's a sub-species of programmer that loves /programming/. Not getting things done with code, but the act of writing code itself. They'll happily over engineer and refactor things for eternity if left unchecked. Leave them alone for two years, come back and ask if Hello World is done? "Not yet, I'm working on optimizing the text to speech plugin api". It's to these people that this article should really be speaking to.

Re: Your code may be elegant, but mine works

#55

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.

Re: Your code may be elegant, but mine works

#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 also accruing revenue immediately, and you can reconcile the debt over time."

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.

I know I'll get a lot of flak for this take, but all I can say is that while I've quit companies like that, I understand why some people couldn't do the same, and at that point it may require some tough love people management in effort to create a brighter future with a healthy work place.

Re: Your code may be elegant, but mine works

#58
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 the right thing or similar arguments as an excuse not to understand an existing codebase and past choices, to convince management or fellow developers to rewrite something that doesn't need to be rewritten, or to buy time to learn and try new technologies/methodologies/patterns that are supposed to be better without understanding tradeoffs or to satiate their desire to overengineer and build a cathedral, when a simple cart would suffice. These efforts acrrue, rather than pay off, actual technical debt. A simple hardcoded one-off is a lot easier to throw away or fix than a half-assed "elegant" design with configuration options and tight coupling everywhere.

All this means developers and managers are correct to be skeptical when another developer talks about technical debt as a reason that they can't do something quickly. It's not that elegance and technical debt and doing the right thing, etc, don't matter.

Re: Your code may be elegant, but mine works

#59
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…

It's also worth noting that he's talking about things like "if your client needs a Christmas promotion and you deliver on Dec 29". This sounds about right. 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 am currently developing and maintaining a s…

> 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 consuming, we have been conditioned to view every piece of code we write as a "will be maintained forever" proposition. You don't generally see people using excel and worrying about the maintainability of their spreadsheets, because even sophisticated spreadsheets are trivial to create and so the default mentality is use and throwaway.

This is a problem we are trying to tackle at my startup, a web developer tool that you can use to quickly put out applications to support day-to-day operations without obsessing about whether you're going to need to build a spaceship out of your current requirement.

Re: Your code may be elegant, but mine works

#60
I'd add more controversy here: if deadline is unrealistic it is ok to miss it and do things the right way.

Deploying ugly piece of shortcut that is going to give you grief for the next 5 years is not worth making for the sake of pulling your skin off to met unrealistic deadline that was created by the layer of clueless management.

Follow your professional intuition of course.

Post reply on HN