I call bullshit. I've worked with some "just get it done programmers'. Have you tried to go into code that someone threw in to just make it work.
Abstraction, interfaces and unit tests are not a leisurely activity for academic developers. We use them to make the code less complex and maintain. The cost of development isn't the initial code base, its the fixes and additional features people want AFTER the initial release(s). Going back into the code and safely making changes or adding code with these in place reduces time.
I had an application without automated testing, it cost the company almost 2000 man hours to test the system every time they made a release.
Design patterns, Joel, are repeatable patterns within code. Design patterns are again to help when another developer goes into the code they can see what the heck the original developer tried to accomplish.
To summarize, I would suggest you out source some code to the far east. They will get it done really fast for you. And yes it will only work 50% of the time. I love buying products that will only work 50% of the time and unfortunately I don't get to pick which 50% works.
I don't think that's the point Joel is making. At the end of the article, it really comes together. Perhaps you are too heavily focused on the specifics (unit testing, etc) instead of the overall theme. He's basically saying that while the other guys are wasting time overengineering a project, sometimes just getting to work and getting started is a much more productive approach.
Joel isn't directly bad-mouthing unit testing or multithreading, but as developers we tend to think about all of these cool toys we can use and "ooooh" and "ahhhh" instead of actually shipping code. Try not to get so hung up on the specifics.
I worked at Orbitz which has a huge Java codebase. It was complex and hard to maintain. It was loaded with abstractions, interfaces and unit tests. I believe the former was mostly due to the latter.
Not to say that the latter has no merits -- there are situations and cases where they are 'net win' good things. But when overdone or done poorly they make a codebase much harder to understand, troubleshoot, extend or fix.
I've seen this first-hand many times, though I notice it most often occurs in large corporate Java shops rather than with smaller companies or codebases or more nimble/concise languages.
I don't think he sees a "duct tape engineer" as a "just get it done programmer." Like he said, they're pretty boys that just look pretty, ie they're rare and have a special balance of pragmatism. JWZ guys are the kinds of wizards you might never work with. We're also talking about a fairly specialized position Netscape was in, that was a company that made a huge amount of money. Have the twitters and facebooks of today made any money yet? Some of those guys at netscape got rich, what can you say to that? They've got scoreboard.
"Just get it done programmers" are a scourge. Most of them have no business deciding which corners to cut, let alone how much to cut them by. There is definitely a balance to achieve. Are you going to ship a "3.0?" Are you building a company to last 5 or 10 years? Or one to last as long as it takes to make the money back and sell? Is this a product you're prepared to get dirty fighting competition with or do you just not care? You never want to over-engineer but cutting too many corners is far worse. If you're a low investment startup with a decent idea, do you honestly think you can put out something that works 50% of the time and even have a shot at a 2.0? Maybe if you've got a proven wizard that spins money out of thin air you duct tape the whole thing like he thinks you should.
If you have investors and you slam out a mediocre 1.0 in like 3 months, will they really sit back for 12 months while you "engineer" 2.0? Or do they want 2.0 in another 3 months?
Comments
I call bullshit. I've worked with some "just get it done programmers'. Have you tried to go into code that someone threw in to just make it work.
Abstraction, interfaces and unit tests are not a leisurely activity for academic developers. We use them to make the code less complex and maintain. The cost of development isn't the initial code base, its the fixes and additional features people want AFTER the initial release(s). Going back into the code and safely making changes or adding code with these in place reduces time.
I had an application without automated testing, it cost the company almost 2000 man hours to test the system every time they made a release.
Design patterns, Joel, are repeatable patterns within code. Design patterns are again to help when another developer goes into the code they can see what the heck the original developer tried to accomplish.
To summarize, I would suggest you out source some code to the far east. They will get it done really fast for you. And yes it will only work 50% of the time. I love buying products that will only work 50% of the time and unfortunately I don't get to pick which 50% works.
I don't think that's the point Joel is making. At the end of the article, it really comes together. Perhaps you are too heavily focused on the specifics (unit testing, etc) instead of the overall theme. He's basically saying that while the other guys are wasting time overengineering a project, sometimes just getting to work and getting started is a much more productive approach.
Joel isn't directly bad-mouthing unit testing or multithreading, but as developers we tend to think about all of these cool toys we can use and "ooooh" and "ahhhh" instead of actually shipping code. Try not to get so hung up on the specifics.
And the guys who will have to maintain that promptly shipped code will say a lot of "wtf?" and waste 10x more time on it.
I worked at Orbitz which has a huge Java codebase. It was complex and hard to maintain. It was loaded with abstractions, interfaces and unit tests. I believe the former was mostly due to the latter.
Not to say that the latter has no merits -- there are situations and cases where they are 'net win' good things. But when overdone or done poorly they make a codebase much harder to understand, troubleshoot, extend or fix.
I've seen this first-hand many times, though I notice it most often occurs in large corporate Java shops rather than with smaller companies or codebases or more nimble/concise languages.
I don't think he sees a "duct tape engineer" as a "just get it done programmer." Like he said, they're pretty boys that just look pretty, ie they're rare and have a special balance of pragmatism. JWZ guys are the kinds of wizards you might never work with. We're also talking about a fairly specialized position Netscape was in, that was a company that made a huge amount of money. Have the twitters and facebooks of today made any money yet? Some of those guys at netscape got rich, what can you say to that? They've got scoreboard.
"Just get it done programmers" are a scourge. Most of them have no business deciding which corners to cut, let alone how much to cut them by. There is definitely a balance to achieve. Are you going to ship a "3.0?" Are you building a company to last 5 or 10 years? Or one to last as long as it takes to make the money back and sell? Is this a product you're prepared to get dirty fighting competition with or do you just not care? You never want to over-engineer but cutting too many corners is far worse. If you're a low investment startup with a decent idea, do you honestly think you can put out something that works 50% of the time and even have a shot at a 2.0? Maybe if you've got a proven wizard that spins money out of thin air you duct tape the whole thing like he thinks you should.
If you have investors and you slam out a mediocre 1.0 in like 3 months, will they really sit back for 12 months while you "engineer" 2.0? Or do they want 2.0 in another 3 months?