
Programmer as Market - DanielBMarkham
http://www.whattofix.com/blog/archives/2011/02/programmer-as-m.php
======
wccrawford
He's got some good points.

The first startup I worked for had really ugly code... That worked. And for
the first couple years, I wrote slightly nicer code that also worked.
Eventually, the product matured enough, and had enough customers, that it was
time to get serious about clean code. I started adding unit tests and cleaning
things up. It was almost impossible to get everyone else on board because they
were used to doing things the 'quick' way for so long.

But eventually it became unbearable to continue as we had. The whole company
got on board with unit tests, then scrum, and eventually ordered a complete
rewrite of the system with clean, maintainable code.

I didn't actually agree with the last bit. I thought incremental changes were
best for most of it, and a complete rewrite for other pieces would be the
best.

The point is, they started out quick and dirty, launched, made some money, and
then started cleaning up. It enabled them to seize the market and hold onto
it, despite competitors that came along and threw millions of dollars into
developing a competing product.

One size does not fit all.

~~~
damoncali
How did the rewrite go? That always scares the crap out of me.

~~~
wccrawford
It had a ridiculous deadline, but it actually seemed to be going well. The
developers (myself included) were more interested in clean, maintainable code
than hitting the deadline, so everything was looking really nice. Most of the
business logic had been done (and unit tested, of course) and already had
another team talking about how they could use it in their code.

Unfortunately, I left the company at that point, so I won't get to see how the
rest of the rewrite goes.

------
hello_moto
This topic (and the replies) are getting boring and boils my blood sometime.
I'm going to rant like I've never ranted before. I'm just pissed.

Yeah, I hear those common "excuses" for not doing TDD/BDD. I also heard why we
need to use BDD, then followed by ATDD, instead of just TDD. I also know the
stories of Facebook, MySpace, Twitter, and other startups that hire super-hot-
shot developers, feed them with pizzas and coke so they can stay up all night
writing code ( _cough_ , I mean, fixing bugs from the code they wrote this
afternoon without unit-tests... _cough_ ).

I mean, here's the thing, if you're in this for the money and fame, then
perhaps you should be honest and say it what it is: "I don't give a F* about
the technology and methodology, I just want to make something people want and
get rich. I wanna hire the best developers out there to deliver me a working
code while I make decision about the product development and business
decisions".

Don't give me the crap about "Changing the world!". You don't plan to change
the world, it's accidental. Nobody knows how to change the world. If you know
how to change the world then you're probably some sort of god or something.

Here's another thing: I don't care whether you use TDD, BDD, ATDD, DDD, XXDD.
I don't. What I'd like to know is that can you write a unit-test to prevent
that stupid bug you caused so that we can detect it faster during build-time
when someone had to modify something that may or may not affect your code?
Don't give me excuses like:

"Oh we can't write unit-test around there because it has hard-dependencies
with a WebService/DB",

"Oh we need to bring up the Web Server because we can't run the tests without
it"

"it takes a lot of time, like 2-3 days to get to the point where we can write
the unit-tests, and we might break some stuffs along the way".

If I keep hearing these kind of excuses, I'll grab an unused keyboard and drag
such developer to the server room. We're going to have a grown-up chat. Nobody
will come out from the room unless my point sticks in the devs's ass. Either
that or until there's no more keys in the keyboard. I'll bury that developers
with books about testing.

How many times we heard the stories that a hot technology companies growth
were uncontrollable and at some point, everything just fall down. Fixing bugs
becoming a drag. The earlier supposedly "hot/superb" developers have left
because things were not going well... and eventually the company dies. Then HN
crowds starting to have a long discussions of the blame game: is it the tech?
is it the leadership? is it the business models? is it the culture? is it the
building? the aeon chair?

I find it funny that the hot-shot developers always left after the initial
rush is gone. You know, when they have to deal with the shitty code they
wrote? remember that time? Nah, they just left for another startups and we (or
at least I) thought they were the cool developers: the "it" team", the "dream"
team, the "3 small productive team by the corner that left because they were
no longer respected". All we heard is that they left because the "culture was
no longer acceptable" or because "management made mistakes". I mean...
c'mon... we're grown ups. These hotshots developers were part of the problem
too.

I just want developers to act like a grown-up. Man-up, fix that code. Make
sure the bug won't show up again in production, if it does, I'll fire your
ass. Don't give me BS. Clean up your own mess. Don't run away. Don't blame
management. Educate the management.

Often people point out that "don't worry, we'll get the market first then
we'll clean up". How often that'll happen? The chances that will happen is
probably 1:20 or 1:50. Most often, the developers have to live with the stuff
for the rest of their careers in that company.

I also find it ironic that many people would give their 2cents (no, more like
their 99cents) especially when they're NOT involved in the situations. When
they are actually involved in such situation, I bet my career that they're
actually screaming, kicking, punching, and yelling for changes, or for better
methodologies/processes, or _gulp_ writing unit-tests. Or they simply quit
their job.

Don't pain a picture that points out how long it takes to write unit-tests. If
it takes too long, you're doing it wrong!. Cut your HN addiction and start
writing those unit-tests. If you need to throw away the code, throw away the
unit-tests as well. It took me less than 5 minutes to write a single unit-
test. It took me less than 5 minutes to delete unused code (both production
and unit-tests).

Yes, I am painting a generalization with a gold brush. This is what happening
in our industry. Don't act like it's a minor problem.

I'm really passionate about this field. But sometime I am considering to join
the hotest startup as tech-lead or management (doesn't matter, as long as I
don't have to deal with craps at 3 AM in the morning), get rich and call it a
day, be an angel, sit down on conferences, just talk, talk, and talk,
following the superstars that HN-ers always praised (the likes of jwz, pg).
One successful exit and people will pray like you're some sort of god or
something. They'll quote you forever.

Feels good to rant. It's been a while.

PS: No, I'm not ranting because I hate my job. In fact, I'm in a good position
right now where people write unit-tests without even being told to.

~~~
DanielBMarkham
_Often people point out that "don't worry, we'll get the market first then
we'll clean up". How often that'll happen? The chances that will happen is
probably 1:20 or 1:50_

No. If you're in a startup 20-1 odds are you never see that code again. Factor
that.

If you're in a spot where the company is making money, you've got an income
stream? Different story entirely.

The point is to do the math. Don't just follow one way or another because you
have some idea of what a "correct" programmer would do.

I have listened to your rant all my life. Hell, I've even been the one giving
it. 99% of the time I was right, because 99% of the time I was talking to a
group that had to maintain whatever they wrote for the next five years. But
when you are in a not-making-money-startup right and you have 200 folks
telling you how to be a great programmer, and not a damn one of them could
make a program on the open market that could make a dime. We have put "quality
programmer" ahead of "make something useful" because we, as programmers, are a
market for other folks to sell us stuff. Our customers are a secondary
consideration to them -- and to us. Something is wrong with that picture.

Love the rant. I especially like it when people tell me and others what a good
or bad programmer is. Hell, I agree with the thrust of your rant. The problem
is that people could give jack shit for a good programmer. They want you to
solve their problems. Then money comes. Then you have a code base that you can
make all nice and shiny and pat yourself on the ass for how great you are. You
can even rant and rave and fire people who don't tow the line like you expect.
But until that happens, you got a pipe dream and 40 tons of useless
architectural and code design cruft you're carrying around between your ears
that you have been sold.

 _How many times we heard the stories that a hot technology companies growth
were uncontrollable and at some point, everything just fall down._

This is one of my favorite canards. Look -- if you're in a technology company
that wrote crap code and now you have a million users? That's not a failure!
That's a success! We should all be so lucky! For every tech startup that wrote
crap code and have a million users there are a _thousand or more_ tech
companies that wrote awesome code that nobody cares about. It's not enough for
those guys to sit around telling themselves how awesome they are, how much
they could scale if they only have users, because _getting users is the whole
freaking point_. Code the Space Shuttle once you can sell a couple of bottle
rockets.

You're not talking to somebody who is saying throw out all your good coding
practices. You're talking to somebody who is telling you to freely adapt with
an open mind to the particular situation you find yourself in.

</counter rant> :)

------
6ren
I _love_ optimizing stuff. But if customers don't care about the code being
faster, my optimization isn't valuable to them. One thing I can do is work in
an area where speed is important at the moment (I say "at the moment", because
it changes over time, as people work at it, and there's always Moore's Law,
there can also be standard library and VM improvements). Example:

John Carmack's genius for graphics optimization was highly valuable for Doom,
because the hardware wasn't powerful enough to do graphics fast enough for
people. Gradually, over time, the hardware has improved, and his talent has
become less important. But recently, with his work on the iPhone, his genius
again becomes crucial, to tweak out every last bit of performance. You can
hear his delight that his favourite skills are important again, at 1:50:
<http://www.youtube.com/watch?v=keu4GiTGQ6M>

On the other hand, I'm doing something very complicated at the moment (for me,
anyway). To be able to reason about this, I have to separate it into modules
that don't interact very much - even if that makes it slower. Because it's not
yet clear exactly what the market wants, I'll need to be able to iterate on
it, doing different experiments, trial-and-error, backtracking. Therefore it
needs to be written in a very simple and straightforward way (no tricks!), so
that I can quickly understand and change it. This amounts to "good design" -
but it's only because that's what's needed.

------
mmphosis
Behavior driven development (BDD)
<http://en.wikipedia.org/wiki/Behavior_Driven_Development>

Test-driven development (TDD) <http://en.wikipedia.org/wiki/Test-
driven_development>

------
samjohn
I once had an interview with Pivotal labs in which I paired with their devs to
do some TDD. We spent about 20% of the time writing code and 80% writing tests
and fixing bugs in the test cases. I can see how it works for what Pivotal
does but this would definitely not fly when you're trying to ship and iterate
as fast as possible.

~~~
bigiain
Keep in mind that sometimes the alternative is to spend 20% of the time
writing code, and 80% of the time fixing bugs that made it into the live
environment and are affecting customers.

I think one of the hard decisions to time correctly when a startup gains
traction is "when do we stop being cowboys, and adopt proper development
practices?". I see (in mysef as well as others) _way_ too much clinging to the
"Oh, I' just ssh into the live server and fix that" kind of behaviour, often
way past the point where that's clearly no longer the right way to proceed...
(and yes, I bit myself with that just last week, again... Ouch!)

~~~
jayunit
your first sentence: nail, head.

------
jasonlotito
Pretty much spot on. We are working to employ TDD and CI/CD where I work, and
I love this. But at home, on my own personal projects, I just love hacking
away. And anything I create just needs to work.

Basically, those that ship win.

~~~
hello_moto
... win temporary before they died within 2-3 years because they can't change
fast enough due to large legacy code.

Either that or expenses goes up cause you have to pay developers ridiculous
salary to work 24/7 (a.k.a don't go home until the bug is fixed).

Same old song. We've seen this once too many until the VHS video is unplayable
anymore.

------
tastybites
MySpace was written in crap-tastic Coldfusion on Windows servers that would
constantly crash. For years it had a single point of failure in the Cisco
switch that demarcated its network border. They got their initial user base by
spamming 50 million email addresses that they used to sell Razr scooters to.

Basically they are the antithesis of everything HN "stands for", if you could
paint with a broad brush.

Defined an industry, an era, and put LA entertainment on the map for internet
media. SOLD.

$580 million.

Overtaken by facebook, written in PHP by some kid in his dorm room, idea
probably stolen and financed through fraud and deception. Horrendous privacy
regime. Redefining the industry, put the northeast on the map for startup
incubation.

Worth billions.

Do I even need to go into Twitter? Scaling difficulties on physical servers
managed by NTT Verio, as old school as it gets. Not a cloud for miles.

Such is the way of the world. All of these companies addressed user needs and
came out on top, all of them had nothing to do with development methodologies
or preferred platforms.

~~~
bigiain
While those three examples are a fine and damning view of "must use the latest
cool-toy web-dev trinkets" development approach, I'd remind you strongly of
the survivor bias...

I suspect a quick poll of HN members could turn up tens of thousands of failed
web startups, both using modern MVC/Ajax/Web2.0/Cloud/buzz-word-de-jour
techniques, as well as hacked up in Perl/CGI or duct-taped to the side of a
Wordpress install.

I'd bet the cross section of new or old technologies used to create a web
based startup is not at all correlated to the success or failure. If the
founder(s) are the sort of people to get the _other_ few dozen (or hundred)
important things about launching a new business right (or at least mostly
closer to right than wrong), then minor hurdles presented by "legacy"
programming techniques are unlikely to have make-or-break effects on the
business outcome.

~~~
tastybites
Yeah, that's my point - it's uncorrelated.

