You Are Not Ruthless Enough | Hacker News Reader

You Are Not Ruthless Enough

playswithfire.com

79 pointswallflower19 comments

You know, these conversations always seemed to come down to discussions of "good code" vs. "ship quickly". I don't think that the point. Getting an MVP to market takes more than one iteration on the code, and even as early as refactor/debugging number 3, you can (and will!) be bit by bugs written in iteration 1 if you're writing bad code. The best stories are always about bad decisions from 6 months ago or more, but this can happen in the course of a single weekend.

Writing good, clear interfaces and using them appropriately does not slow you down. It lets you move faster, think clearly, solve harder problems, and build more.

a lot of projects are taking a soft process, like legal compliance, and trying to automate it. when you have requirements like < http://c2.com/cgi/wiki?WhyIsPayrollHard > perhaps the best factoring of interfaces, the best set of metaphors, aren't obvious, or are shifting. It certainly isn't something you can get right on the first try - if it was, we'd just Waterfall it and call it a day. So, yes, it is precisely a balance between future agility and shipping now - except if you don't ship now, you might not need the future agility ;)

me saying this is particularly ironic because i'm the guy pushing scala adoption, clean code, fixing our abstractions, etc. i'm also less valueable to the business over the one-year timeframe that dictates my comp because of it. The only people incented to relenentlessly care about things like technical debt are those with equity.

Oh, for sure. I'm not advocating getting it right on the first try -- that's crazy talk.

I'm mostly thinking about programming in the small: methods, classes, parameter lists, that sort of thing. Essentially complex problems can't (and shouldn't) be solved up front, but that doesn't imply the internals of that partially-solved problem should be disorganized, or that the API is inconsistent. I find that if I explicitly scope my work as I'm doing it, I can write good code to fuzzy specs, without over-generalizing, relatively quickly. Plus, coming back to it a couple months later (well within the typical employee-raise timeframe), I can fix or modify it much faster.

It's a balance, to be sure, but I think it's sometimes possible to work both faster and better.

In the past, I too would have thought that good code needs to take a backseat when shipping is a priority. But now I have realizes that if I just think for about 5-10 minutes, I am able to avoid a lot of mess for almost no penalty in shipping time.

Good design keeps things clear in code and in your mind. It can handle changes a whole lot better as well.

so the thing is, this is very difficult to quantify and thus talk about. It also totally depends on the size of your codebase, the size of the team, and the timeframe of the business. if anything, i would have even higher value to my current employer by being less ruthless - we have necessarily tight business windows, and as the deadline looms closer, we slide back on quality to hit it.

5 years ago i was reading code complete and all those books, and whined a lot about all the poorly factored code in its interleaved and tangled glory. I thought I was the best programmer ever and took pride in my perfectly factored little modules. As I get older, I have a lot more respect for my elders and betters - they are solving harder problems than I am, problems that if I had attempted I would have a perfectly factored solution that meets half the requirements. Is it a bitch to maintain all that Java? it sure is, but we're all well paid, and our customers are begging us to bid on proposals we don't even want.

If you're building a project from scratch, I think you have to be more ruthless with your time than your objects. In the early stages of a product it's easy and cheap to refactor if you find your devspeed slowing down because of poor coding choices you've made.

Trying to get it right first time off leads to second system syndrome or overly complicated and meta fundamentals (if you are doing it first time).

In my experience, this holds true ESPECIALLY when working on existing systems whose behavior you don't understand completely. If you or someone else is the author is irrelevant here.

To get it right you have to screw it up first. The hacked up version may or may not get into production (depends on the scope). What one should do is gain intimate knowledge of a particular system/module and keep up to date with it. When you start implementing something big, you have no idea what it really takes, thus abstractions make no sense. Just use the goddamn duct tape and zipties. Then fix it as you figure out how it ought to be - and don't fret over it, you WILL change it again tomorrow.

But one should always strive to do it as right as possible, given the current circumstance. One should also

Good software is grown and it takes time, knowledge and patience. I liken it to drawing Silicon mono crystal for semiconductor waffers.

Brilliant stuff, but ignores the fact that the market rewards the first mover, not the guy who came later with something better.

Really? I could have sworn google weren't the first search engine on the block, and Apple wasn't the first person to make 'smart' phones.

Apple will never be the first "person" to do anything.

With that said, point taken.

Corporations are people too.

I'll believe that when Texas executes one of them.

Except for all the cases where the guy who came in later had his shit together (unlike the incumbents) and took over.

That's about completely changing the game, though. You can't beat an incumbent, just by doing the same thing as he is, but better. You need a product that changes a lot of the rules of the competition in that market, and then you need for the market and customers to follow that vision as well. Only then an incumbent can be beaten because they will be slow to adapt to the new rules.

Right, but to be the first mover you need to at least get most of the idearight. Just because you got a shitty landing page website up first doesn't mean you can't get steamrolled two months later by somebody who had his stuff together.

"First-mover advantage" is overrated and can be nullified by lack of resources, free-rider effects, and API closings.

EDIT: closures > closings

Real cool, must when it comes to actually writing code:

- UITableView approach is megalomaniacal, could use some love.

- XCode sometimes sends you straight to the subclassing hell. Specially if you don't have a well defined model before you start dragging stuff into your storyboard.

- Lots of iOS SDK classes will help you into taking the anti-pattern road. For instance: UIView:UIResponder.

I'm convinced you shouldn't be allowed to write production code unless you've read and understood The Pragmatic Programmer.

"Every time you throw in something that seems to work, find out why it works."

This. Especially for bugs. If I don't know why its fixed, I haven't fixed the cause - I've fixed a symptom.

Reply on news.ycombinator.com