
You Are Not Ruthless Enough - wallflower
http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/
======
trjordan
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.

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

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

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

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

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

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

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

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

With that said, point taken.

~~~
aMoniker
Corporations are people too.

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

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

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

------
buff-a
"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.

