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.
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.
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.
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.
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!)
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.
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.
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.
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.
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.
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.