[huckfinnaafb]

There's good code, which is something that good products build their foundation on, and near perfect code, which can get in the way of building realistic solutions on time.

>Do you really need a full objet-oriented API right now? Do you really need to make a dozen interwoven classes, when it’s possible just a hundred or so lines in one class will do fine? Can you do all the same error checking and unit tests in a much smaller code base?

This is not necessarily "good code". That's code you think is good. Excessive or complex code is not good code, and I think the author should redefine his usage to what programmers sometimes perceive as good code.

[abk]

I was just about to post the same thing. I agree with the underlying thesis that a good shipping product is better than perfect code that never ships, but the author seems to be confusing good code and over-engineering.

Good code does exactly what it needs to, but will be maintainable and won't have to be thrown away when that "fantastic" product ends up getting popular.

I also tend to believe that doing it right doesn't necessarily take much longer. The code I write now is much better than the code I wrote 10 years ago for a number of reasons, but I still get a lot more done, and a lot faster than I did back then.

[alexobenauer]

That's a great distinction. As you saw, the definition of 'good code' for this post was definitely based on the 'good code' remarks I hear from coworkers, where it is often the notion that more objects, bigger API's, etc., is 'good code' and a 100 line one-class add-on is 'bad code'. Great distinction though, thanks for bringing this up!

[pacala]

>Do you really need a full objet-oriented API right now? Do you really need to make a dozen interwoven classes, when it’s possible just a hundred or so lines in one class will do fine? Can you do all the same error checking and unit tests in a much smaller code base?

Do you really need to split your data into small pieces, when you can use global variables and have a code-base that eliminates the need for function arguments and complicated function invokation strategies in a much smaller code base?

While the fight for proper functions has been largely won thanks to unit testing, a lot of people think that the database gives them back the license to code against global state and believe a code-base should be judged by the number of keystrokes needed to type it.