4 ms·

Even in a seed-stage startup, you'll often wind up doing heavy refactoring and redesign. Let's say you've just spent two weeks building a prototype billing sys

by ekidd 15y ago

Even in a seed-stage startup, you'll often wind up doing heavy refactoring and redesign. Let's say you've just spent two weeks building a prototype billing system, and you demo it to some potential customers. They get excited, but they ask for time-tracking features. So you add some. Great! Now, what about your old features? Do they still work, or did you break them? In my case, I just tweak 2 or 3 acceptance tests, watch everything go green, smoke test for 2 minutes, and run 'git push heroku'. Without unit tests, I'd waste the next hour carefully hand-testing all my features. Now, this might not fit your personal coding style. That's fine. But tests actually let me go faster, even on a 3-day project. In a seed-stage startup, you need to get in as many iterations as possible before you run out of money.

DanielBMarkham 15y ago
Apologies if I did a poor job explaining. Perhaps I should restate. Yes, test first. But the test is user wants, not code functionality. So to your example, you sell a mock-up. If they want it, then you go back and test-first and code. If you can find out they want time tracking without coding, what are you coding for? If you are coding one thing and they really want something else, what are you coding for? I'd argue that if you have customers that are directing your sprints, timeboxes, or whatever, then you're already past the point I am talking about. They have money, they have needs, they express needs to you and you go fill them. This is a great spot to be in as a startup! But at that point you're really just quasi-business programmers, and all Bob says is very applicable. The guys I hear who do well always regret that they spend too much time on stuff that doesn't matter: coding, business plans, reading business books. Instead they should have just worked out more effective ways to find out what people want. If you have a Minimum Viable Product that people want to pay money for, go code it. And do a good job of it, because you've already determined that people are going to pay money for it. So in that scenario, if you misunderstood your MVP, then all that TDD is going to be awesome when you refactor. There's a third scenario that's being hinted at: you don't know what people might want, but you think you should code anyway to find out. This is like building a runway hoping that an airplane will suddenly have an emergency and need a place to land. I'd argue that you should either avoid this at all costs, or if you must code, write the cheapest, fastest throwaway crap you could imagine -- the odds are very, very high that you will never use or see that code again. If you do? You hit the lottery, and worrying about how badly you coded something is a ridiculous thing to get uptight about. Every second you spend creating an artificial world, whether that's a business plan, program, or sales chart, without validating with the customer is a waste of energy for an early startup.
- ekidd 15y ago
  We're in violent agreement that startups should write as little code as humanly possible. I learned that lesson the hard way. You should test your ideas first. But sooner or later, you'll get a rough idea of what people need, and you'll throw together a working prototype. After all, users don't visualize well, but they're great at extrapolating from things they can see. That's when I start writing tests, even if it's just a weekend prototype. Because for me, tests are a net win by the afternoon of day 1. Why should I spent 3 days writing nasty crap when I could have a decent program in 2? Now, this won't work for everybody. Maybe it takes a month to prototype your idea. Maybe it takes you twice as long to do TDD as it does to churn out code. Maybe your idea is just plain hard to test. But I'm definitely in complete agreement about customer validation.
- Produce 15y ago
  >But the test is user wants, not code functionality. I often advocate functional and integration tests over unit tests for this very reason. A good functional test is testing use cases, which is exactly what the customer wants! Unit tests exist primarily to improve code quality and aren't very useful for anything else.
- losethos 15y ago
  Let me google that for you: http://lmgtfy.com/?q=64-bit+operating+system http://lmgtfy.com/?q=64-bit+operating+system I have done better than all these: http://wiki.osdev.org/Projects http://wiki.osdev.org/Projects Linux is free. I can't charge, but might down the road, except I promised I wouldn't. It's a good thing I'nm disabled because there doesn't seem like any way to make money. God says... C:\TEXT\PLATO.TXT ent of the rulers, because I knew that the perfect State would be eyed with jealousy and was difficult of attainment; but that piece of cleverness was not of much service to me, for I had to discuss them all the same. The women and children are now disposed of, but the other question of the rulers must be investigated from the very beginning. We were saying, as you will remember, that they were to be lovers of their country, tried by the test of pleasures and pains, and neither in hardships, nor ----- My reality is not right. My download numbers seem like fiction and all I get are emails from the FBI. Therefore, I probably shouldn't rejoice too much in top Google ranking. Oh well. My reality is unusually good in many ways, too, so I guess I shouldn't complain. God says... dreams necessary formerly forgave nominally seven dispose original multitudes foregoing discommended smoothed admonished deferred helping

by ekidd 15y ago

DanielBMarkham 15y ago

Apologies if I did a poor job explaining. Perhaps I should restate. Yes, test first. But the test is user wants, not code functionality. So to your example, you sell a mock-up. If they want it, then you go back and test-first and code. If you can find out they want time tracking without coding, what are you coding for? If you are coding one thing and they really want something else, what are you coding for? I'd argue that if you have customers that are directing your sprints, timeboxes, or whatever, then you're already past the point I am talking about. They have money, they have needs, they express needs to you and you go fill them. This is a great spot to be in as a startup! But at that point you're really just quasi-business programmers, and all Bob says is very applicable. The guys I hear who do well always regret that they spend too much time on stuff that doesn't matter: coding, business plans, reading business books. Instead they should have just worked out more effective ways to find out what people want. If you have a Minimum Viable Product that people want to pay money for, go code it. And do a good job of it, because you've already determined that people are going to pay money for it. So in that scenario, if you misunderstood your MVP, then all that TDD is going to be awesome when you refactor. There's a third scenario that's being hinted at: you don't know what people might want, but you think you should code anyway to find out. This is like building a runway hoping that an airplane will suddenly have an emergency and need a place to land. I'd argue that you should either avoid this at all costs, or if you must code, write the cheapest, fastest throwaway crap you could imagine -- the odds are very, very high that you will never use or see that code again. If you do? You hit the lottery, and worrying about how badly you coded something is a ridiculous thing to get uptight about. Every second you spend creating an artificial world, whether that's a business plan, program, or sales chart, without validating with the customer is a waste of energy for an early startup.

ekidd 15y ago
We're in violent agreement that startups should write as little code as humanly possible. I learned that lesson the hard way. You should test your ideas first. But sooner or later, you'll get a rough idea of what people need, and you'll throw together a working prototype. After all, users don't visualize well, but they're great at extrapolating from things they can see. That's when I start writing tests, even if it's just a weekend prototype. Because for me, tests are a net win by the afternoon of day 1. Why should I spent 3 days writing nasty crap when I could have a decent program in 2? Now, this won't work for everybody. Maybe it takes a month to prototype your idea. Maybe it takes you twice as long to do TDD as it does to churn out code. Maybe your idea is just plain hard to test. But I'm definitely in complete agreement about customer validation.
Produce 15y ago
>But the test is user wants, not code functionality. I often advocate functional and integration tests over unit tests for this very reason. A good functional test is testing use cases, which is exactly what the customer wants! Unit tests exist primarily to improve code quality and aren't very useful for anything else.
losethos 15y ago
Let me google that for you: http://lmgtfy.com/?q=64-bit+operating+system http://lmgtfy.com/?q=64-bit+operating+system I have done better than all these: http://wiki.osdev.org/Projects http://wiki.osdev.org/Projects Linux is free. I can't charge, but might down the road, except I promised I wouldn't. It's a good thing I'nm disabled because there doesn't seem like any way to make money. God says... C:\TEXT\PLATO.TXT ent of the rulers, because I knew that the perfect State would be eyed with jealousy and was difficult of attainment; but that piece of cleverness was not of much service to me, for I had to discuss them all the same. The women and children are now disposed of, but the other question of the rulers must be investigated from the very beginning. We were saying, as you will remember, that they were to be lovers of their country, tried by the test of pleasures and pains, and neither in hardships, nor ----- My reality is not right. My download numbers seem like fiction and all I get are emails from the FBI. Therefore, I probably shouldn't rejoice too much in top Google ranking. Oh well. My reality is unusually good in many ways, too, so I guess I shouldn't complain. God says... dreams necessary formerly forgave nominally seven dispose original multitudes foregoing discommended smoothed admonished deferred helping