5 ms·

I'd go as far as saying clean code as an anti thesis to starting a business. Clean code is a huge battle in itself but not the battle you need to win when start

by tnolet 8y ago

I'd go as far as saying clean code as an anti thesis to starting a business. Clean code is a huge battle in itself but not the battle you need to win when starting a business. Clean UI though is a different story.

cutler 8y ago
Thank $$d someone someone else thinks this. I would add that TDD is a joke if you're serious about getting a product out as quickly as you can. TDD stifles that essential, fast-paced creative process like nothing else. Tests are fine. It's just TDD I have a problem with. If you have plenty of VC money to burn sure, burn it on TDD but if you're on a tight budget it will kill your ability to ship.
- tnolet 8y ago
  The problem often is many people take statements like mine “clean code is anti starting a business” much to literal. Your code needs to be somewhat clean, just clean enough to make it to the next round. You could do TDD on that one part that is super duper critical, just not on the part that is doing basic API stuff or something run of the mill. I guess assessing nuance is hard.
- briandear 8y ago
  I couldn’t disagree more. TDD makes it possible to ship a more reliable product without superfluous code. TDD also makes it possible to move more quickly without breaking things. That “fast-paced creative process” turns into an albatross when your new stuff is breaking the old. The VC types are the ones that can actually forgo TDD because you can simply hire a lot of QA. When you are trying to ship “fast,” TDD reduces QA time and also ensures that your developers aren’t breaking each other’s work. I have hired by plenty of test-optional companies and they struggle with adding features or wonder why their application slows to a crawl with even a few hundred users — yet without tests fixing those problems results in new development grinding to a halt. In XP parlance, a spike is specifically to allow for rapid development of a feature idea, but your entire development process ought not be a spike or it will bite you in the ass much sooner than you think and at a point where you can least afford it: when you have some mild, but not strong traction and churning users from buggy code is a real problem. Unless you have some viral-type product (like Facebook,) move fast and break things is a terrible strategy if you care about creating a sustainable business. Make it work, make it scale, make it elegant is smart advice, but part of “make it work” means that it doesn’t break. I would argue that pure TDD isn’t necessary, but I would adamantly suggest that shipping code without tests is far more risky than just hoping you catch issues when clicking through the application. Whether you write tests first or code first, that isn’t the issue — as long as you have tests before you ship. If you fail enough times with building a business, that’s the first thing you’ll learn.
  - bigtunacan 8y ago
    Total BS. That is the bill of goods sold by TDD. In TDD the tests become as critical as the code and they are an anchor that weighs you down and slows down time to delivery. It isn't that tests are bad. Build the code, write tests to support anything critical that is a risk, but for the sake of all that is good throw out writing tests first or any notion of 100% test coverage. It's a huge time suck that does not balance out in the end.
    - LanceH 8y ago
      I hate on TDD as much as anyone, but there really are occasions for its use. Specifically when the results of working code can't be determined by the person running it. The simplest example I can think of is something like a math library -- if I have code that computes the cosecant of x, I don't really know if it's working or not. On the other hand, I really don't need controller tests for my 1.0 version -- if they aren't working, it's immediately obvious. Circle back later and throw a test on it to nail it in place if need be, but TDD is absolutely not needed when development is obvious.
  - Delmania 8y ago
    If you've failed multiple times trying to start a business, I'll guarantee is not because of my doing TDF but because of poor product market fit. You'd be surprised how much crap a user will put up with of your products fit their needs.
louiswilbrink 8y ago
I want to ship complete code ASAP. However, I would allow for refactoring that deletes large swaths of code. This keeps the codebase lean and maintenance low — so that you can keep up the fast pace.

by tnolet 8y ago

cutler 8y ago

Thank $$d someone someone else thinks this. I would add that TDD is a joke if you're serious about getting a product out as quickly as you can. TDD stifles that essential, fast-paced creative process like nothing else. Tests are fine. It's just TDD I have a problem with. If you have plenty of VC money to burn sure, burn it on TDD but if you're on a tight budget it will kill your ability to ship.

tnolet 8y ago
The problem often is many people take statements like mine “clean code is anti starting a business” much to literal. Your code needs to be somewhat clean, just clean enough to make it to the next round. You could do TDD on that one part that is super duper critical, just not on the part that is doing basic API stuff or something run of the mill. I guess assessing nuance is hard.
briandear 8y ago
I couldn’t disagree more. TDD makes it possible to ship a more reliable product without superfluous code. TDD also makes it possible to move more quickly without breaking things. That “fast-paced creative process” turns into an albatross when your new stuff is breaking the old. The VC types are the ones that can actually forgo TDD because you can simply hire a lot of QA. When you are trying to ship “fast,” TDD reduces QA time and also ensures that your developers aren’t breaking each other’s work. I have hired by plenty of test-optional companies and they struggle with adding features or wonder why their application slows to a crawl with even a few hundred users — yet without tests fixing those problems results in new development grinding to a halt. In XP parlance, a spike is specifically to allow for rapid development of a feature idea, but your entire development process ought not be a spike or it will bite you in the ass much sooner than you think and at a point where you can least afford it: when you have some mild, but not strong traction and churning users from buggy code is a real problem. Unless you have some viral-type product (like Facebook,) move fast and break things is a terrible strategy if you care about creating a sustainable business. Make it work, make it scale, make it elegant is smart advice, but part of “make it work” means that it doesn’t break. I would argue that pure TDD isn’t necessary, but I would adamantly suggest that shipping code without tests is far more risky than just hoping you catch issues when clicking through the application. Whether you write tests first or code first, that isn’t the issue — as long as you have tests before you ship. If you fail enough times with building a business, that’s the first thing you’ll learn.
- bigtunacan 8y ago
  Total BS. That is the bill of goods sold by TDD. In TDD the tests become as critical as the code and they are an anchor that weighs you down and slows down time to delivery. It isn't that tests are bad. Build the code, write tests to support anything critical that is a risk, but for the sake of all that is good throw out writing tests first or any notion of 100% test coverage. It's a huge time suck that does not balance out in the end.
  - LanceH 8y ago
    I hate on TDD as much as anyone, but there really are occasions for its use. Specifically when the results of working code can't be determined by the person running it. The simplest example I can think of is something like a math library -- if I have code that computes the cosecant of x, I don't really know if it's working or not. On the other hand, I really don't need controller tests for my 1.0 version -- if they aren't working, it's immediately obvious. Circle back later and throw a test on it to nail it in place if need be, but TDD is absolutely not needed when development is obvious.
- Delmania 8y ago
  If you've failed multiple times trying to start a business, I'll guarantee is not because of my doing TDF but because of poor product market fit. You'd be surprised how much crap a user will put up with of your products fit their needs.

louiswilbrink 8y ago

I want to ship complete code ASAP. However, I would allow for refactoring that deletes large swaths of code. This keeps the codebase lean and maintenance low — so that you can keep up the fast pace.