6 ms·

It sounds like you might not have the right mindset for being a technical startup founder. Unit tests and code coverage is anticorrelated with success. With a

by dannyw 6y ago

It sounds like you might not have the right mindset for being a technical startup founder. Unit tests and code coverage is anticorrelated with success. With a startup, your goal is to iterate the fastest. You cannot afford to be spending more than 1 day of time on your continuous deploy system before you have your first paying client. Given the size to your team, you should also have been spending near zero time on documentation. Documentation should be in the form of sticky notes and Slack messages. I think you’re very talented technically, but you should not work on startups until you are able to emulate more of the successful technical cofounder patterns. If your code and processes can scale to 100x of your time expected volume, this is almost universally a sign that you have failed to optimise for what matters. This also goes even if you’re building something like AWS. AWS engineers do not build over-engineered systems that can handle 100d of its expected volume.

marcus_holmes 6y ago
I find this weird. Automated testing has saved me so much time. If I don't have tests and make a change, I have to manually go through a whole set of checks to make sure I didn't break anything. If I have a test suite, it will tell me in 2 minutes if I broke anything. The thing I'm working on at the moment has tests on the backend but not on the UI. I can definitely say the UI work is slower because of the lack of tests.
- burnthrow 6y ago
  Test suite is not free to create or maintain. To your example, for a product that isn't mature, a UI test suite is a waste of time and greatly increases the cost of UI changes.
  - marcus_holmes 6y ago
    This is what I don't get - a test suite saves me time. So, yes, it is free to create and maintain. Because it's much quicker to find regression bugs with automated testing than with manual testing. And this is massively more valuable when things are changing rapidly.
    - dstick 6y ago
      I think the core of what they're trying to get at is: let the users find those bugs. The business isn't large enough to focus on details, yet. In the future, when fixing bugs takes more time than making features, you should have the money to hire more hands and focus more on testing. If you don't, then you built too much product for too little clients which is a problem in and of itself ;-) The cost/benefit isn't there in the beginning. All the bugs are either obvious, easy to find, or quickly discovered without a test suite. So save the time writing tests to stamp out more features the customer wants!
      - marcus_holmes 6y ago
        Adding features adds complexity. Features interact with each other in complex ways. If you add a feature and don't know quickly if it broke another feature, that costs time. Letting the users find the bugs costs time - you have to talk to the user, replicate the bug report, find the failure, fix it, and then release. Finding that same bug 2 minutes after you wrote it (and before it got released) is massively quicker. This feels like one of those "write code 16 hours a day to make more progress!" things that experience has taught me just doesn't work in practice. I feel like I'm making a lot of progress, but after about 10 hours most of the code I write is pure shite and needs to be rewritten the next day. I've found that it's actually way faster to quit coding after 8-10 hours rather than spend 2 hours the next day rewriting everything I wrote in the last 6 hours the day before.
        deleted 6y ago
        [deleted]
        deleted 6y ago
        [deleted]
        burnthrow 6y ago
        > finding that same bug 2 minutes after you wrote it (and before it got released) is massively quicker. That's not realistic. Your last paragraph about overwork seems unrelated to TDD dogma.
- varjag 6y ago
  You're essentially in prototyping phase. Inevitably you'll have to discard whole chunks of code, because your understanding of requirements/concept space changes. Then you have to discard both your code and your fine tests, wasting ~2x more time.
  - marcus_holmes 6y ago
    Yes, but writing tests isn't a huge cost if you're used to it. And once I've discarded that huge chunk of code, I immediately know what else I broke, rather than having to find it by testing manually. If I have to write 100 lines of code to implement a feature, it really doesn't take me twice as long to write another 100 to test it. In most cases, writing the test alongside (or even before) the code helps with writing the code. I'd say writing a test adds maybe 25% to the time. Knowing a year later than that code is still good, because that test still runs successfully, is easily worth that 25% Of course I'm not saying 100% code coverage is worth it. Just the critical bits.
    - burnthrow 6y ago
      Thoughts of "a year later" and MVP mostly don't mix. Agreed about coverage.
- lubujackson 6y ago
  The mindset and goals are much different. At the extreme, a showstopper bug in an MVP is not a big deal - you have few (if any) customers and a glitch here and there won't make any difference in the long run. Early stage tech founder should be either a cowboy programmer or a business-minded project manager, the type who ruthlessly kills projects and blows things up on a whim.
- marcosdumay 6y ago
  That's completely dependent on what kind of software you are writing. (And yeah, if you caught yourself automating UI tests, you are probably way too far.) The best phrasing is the OP's in that "automated tests are anticorrelated to success" (so is posting on HN, by the way). That doesn't mean that for your exact case they are not essential, just that there is an statistic relation.
dSebastien 6y ago
Indeed. The required mental shift became much more apparent to me in the recent months. I guess I'm slow :)
- soneca 6y ago
  I don’t think that you are slow or not a good developer is the right conclusion. I think you focused on the wrong things. Like code coverage, CI, etc. You mentioned of being afraid of your codebase exploding in other comment. You know code don’t really explode, right? The worst case is you will need some refactor down the road. Nothing worse than that.

by dannyw 6y ago

marcus_holmes 6y ago

I find this weird. Automated testing has saved me so much time. If I don't have tests and make a change, I have to manually go through a whole set of checks to make sure I didn't break anything. If I have a test suite, it will tell me in 2 minutes if I broke anything. The thing I'm working on at the moment has tests on the backend but not on the UI. I can definitely say the UI work is slower because of the lack of tests.

burnthrow 6y ago
Test suite is not free to create or maintain. To your example, for a product that isn't mature, a UI test suite is a waste of time and greatly increases the cost of UI changes.
- marcus_holmes 6y ago
  This is what I don't get - a test suite saves me time. So, yes, it is free to create and maintain. Because it's much quicker to find regression bugs with automated testing than with manual testing. And this is massively more valuable when things are changing rapidly.
  - dstick 6y ago
    I think the core of what they're trying to get at is: let the users find those bugs. The business isn't large enough to focus on details, yet. In the future, when fixing bugs takes more time than making features, you should have the money to hire more hands and focus more on testing. If you don't, then you built too much product for too little clients which is a problem in and of itself ;-) The cost/benefit isn't there in the beginning. All the bugs are either obvious, easy to find, or quickly discovered without a test suite. So save the time writing tests to stamp out more features the customer wants!
    - marcus_holmes 6y ago
      Adding features adds complexity. Features interact with each other in complex ways. If you add a feature and don't know quickly if it broke another feature, that costs time. Letting the users find the bugs costs time - you have to talk to the user, replicate the bug report, find the failure, fix it, and then release. Finding that same bug 2 minutes after you wrote it (and before it got released) is massively quicker. This feels like one of those "write code 16 hours a day to make more progress!" things that experience has taught me just doesn't work in practice. I feel like I'm making a lot of progress, but after about 10 hours most of the code I write is pure shite and needs to be rewritten the next day. I've found that it's actually way faster to quit coding after 8-10 hours rather than spend 2 hours the next day rewriting everything I wrote in the last 6 hours the day before.
      - deleted 6y ago
        [deleted]
      - deleted 6y ago
        [deleted]
      - burnthrow 6y ago
        > finding that same bug 2 minutes after you wrote it (and before it got released) is massively quicker. That's not realistic. Your last paragraph about overwork seems unrelated to TDD dogma.
varjag 6y ago
You're essentially in prototyping phase. Inevitably you'll have to discard whole chunks of code, because your understanding of requirements/concept space changes. Then you have to discard both your code and your fine tests, wasting ~2x more time.
- marcus_holmes 6y ago
  Yes, but writing tests isn't a huge cost if you're used to it. And once I've discarded that huge chunk of code, I immediately know what else I broke, rather than having to find it by testing manually. If I have to write 100 lines of code to implement a feature, it really doesn't take me twice as long to write another 100 to test it. In most cases, writing the test alongside (or even before) the code helps with writing the code. I'd say writing a test adds maybe 25% to the time. Knowing a year later than that code is still good, because that test still runs successfully, is easily worth that 25% Of course I'm not saying 100% code coverage is worth it. Just the critical bits.
  - burnthrow 6y ago
    Thoughts of "a year later" and MVP mostly don't mix. Agreed about coverage.
lubujackson 6y ago
The mindset and goals are much different. At the extreme, a showstopper bug in an MVP is not a big deal - you have few (if any) customers and a glitch here and there won't make any difference in the long run. Early stage tech founder should be either a cowboy programmer or a business-minded project manager, the type who ruthlessly kills projects and blows things up on a whim.
marcosdumay 6y ago
That's completely dependent on what kind of software you are writing. (And yeah, if you caught yourself automating UI tests, you are probably way too far.) The best phrasing is the OP's in that "automated tests are anticorrelated to success" (so is posting on HN, by the way). That doesn't mean that for your exact case they are not essential, just that there is an statistic relation.

dSebastien 6y ago

Indeed. The required mental shift became much more apparent to me in the recent months. I guess I'm slow :)

soneca 6y ago
I don’t think that you are slow or not a good developer is the right conclusion. I think you focused on the wrong things. Like code coverage, CI, etc. You mentioned of being afraid of your codebase exploding in other comment. You know code don’t really explode, right? The worst case is you will need some refactor down the road. Nothing worse than that.