Programmer as Market

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.

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.

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

Basically, those that ship win.

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.

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.