3 ms·

He really wasn't pushing a document heavy, he thins man of the so called docs could be in emails, with very quick statements. It just avoid confusion of beginni

He really wasn't pushing a document heavy, he thins man of the so called docs could be in emails, with very quick statements. It just avoid confusion of beginning down a path for a few hours, when there was a minor communication error. He said one of the things he hates the most is when you send a requirement off to an engineer and 3 hours later you get back, a working feature, documentation, and a spec. then if it doesn't match the initial concept a bunch of time has just been blown. Just to give some perspective, Niel is a CS grad and has plenty of engineering in his background. He said he gets why engineers fight back so much, but it hurts the project as a whole.

swombat 18y ago
Well, reading the article, there's hints of a somewhat heavier process. For instance: A spec is well written when QA can figure out how to test a feature based on the spec. I'd reply that in an early start-up team, everyone does QA. Again, if they don't, you've failed. Dev silos in a start-up? Are you kidding? If anyone on the product team doesn't know the product well enough to do the QA without being told what to test, you're, once again, completely screwed. Also: It came across that it wasn’t important what system was used, but that everyone at every stage of the project must write things down. Again... if you're having to write everything down to clarify communications, you're pretty shafted. I know why it's important to write everything down. I did work 4 years as a consultant, and in a corporate environment it is important simply because there is a huge potential for miscommunication, and writing things down reduces that potential and also covers your ass. But in an early stage start-up, both of those tips will kill your start-up much faster than any so-called "wasted time". Ultimately, all of that advice is good advice under certain circumstances. But not in a start-up. It's a different kind of beast, and I'd wager the author or the speaker lack start-up experience to be making these kinds of statements.
- wastedbrains 18y ago
  Niel is currently working on his 3rd startup, two successful so far. I think he knows the early stage start ups pretty well. I know what you mean about getting bogged down in writing everything down. I have had a hard time getting away from verbal communication and just working on my own as well. I can recall various times it has led to problems and spending time on the wrong things though. I think he basically pushes to be fast but still have some documentation, because the few missteps you make, will waste more time than you think you are saving. Everyone should be able to QA, but manually QAing or forgetting to QA something because it was a weird edge case can really hurt or slow you down. We try to deal with this by avoiding manual QA we don't want people wasting time going through the product QAing it over and over, we rely more on automated testing. If you believe that a few short emails back and forth and IMs to keep people on the same page means your shafted,I guess we just have a different value on 30 minutes of non development time a day. I think in our last start up to much head down development killed the startup. Which isn't related to the documentation vs non documentation issue, but was still a PM mistake on our part.

swombat 18y ago

Well, reading the article, there's hints of a somewhat heavier process. For instance: A spec is well written when QA can figure out how to test a feature based on the spec. I'd reply that in an early start-up team, everyone does QA. Again, if they don't, you've failed. Dev silos in a start-up? Are you kidding? If anyone on the product team doesn't know the product well enough to do the QA without being told what to test, you're, once again, completely screwed. Also: It came across that it wasn’t important what system was used, but that everyone at every stage of the project must write things down. Again... if you're having to write everything down to clarify communications, you're pretty shafted. I know why it's important to write everything down. I did work 4 years as a consultant, and in a corporate environment it is important simply because there is a huge potential for miscommunication, and writing things down reduces that potential and also covers your ass. But in an early stage start-up, both of those tips will kill your start-up much faster than any so-called "wasted time". Ultimately, all of that advice is good advice under certain circumstances. But not in a start-up. It's a different kind of beast, and I'd wager the author or the speaker lack start-up experience to be making these kinds of statements.

wastedbrains 18y ago
Niel is currently working on his 3rd startup, two successful so far. I think he knows the early stage start ups pretty well. I know what you mean about getting bogged down in writing everything down. I have had a hard time getting away from verbal communication and just working on my own as well. I can recall various times it has led to problems and spending time on the wrong things though. I think he basically pushes to be fast but still have some documentation, because the few missteps you make, will waste more time than you think you are saving. Everyone should be able to QA, but manually QAing or forgetting to QA something because it was a weird edge case can really hurt or slow you down. We try to deal with this by avoiding manual QA we don't want people wasting time going through the product QAing it over and over, we rely more on automated testing. If you believe that a few short emails back and forth and IMs to keep people on the same page means your shafted,I guess we just have a different value on 30 minutes of non development time a day. I think in our last start up to much head down development killed the startup. Which isn't related to the documentation vs non documentation issue, but was still a PM mistake on our part.