12 ms·

I would expect most to be disappointing too, and it's a good idea to avoid those. Proper logging doesn't take more time, it just takes more discipline / giving

by latch 8y ago

I would expect most to be disappointing too, and it's a good idea to avoid those. Proper logging doesn't take more time, it just takes more discipline / giving a damn. People and companies that say: we don't have time to do it right Almost always mean: we don't know how to do it right Talent, not time, is the enemy of quality. (at some point that stops being true, but most companies (startups or not) are soooo far from that). If we are talking about a really young/small startup and you're a senior person, then you need to have a discussion about it with whoever you answer to. If we're talking about a really young/small startup and you're a jr person, you'll just learn a bunch of shitty habits. If we're talking about an older/larger startup, then you have a problem.

pmart123 8y ago
Maybe the context of the answer is more valuable than the answer in this case? i.e. we have 95% coverage on our core IP and CI setup for all of our source code. But, we integrated X for that service to get off the ground quickly, which will be too expensive at scale so we didn’t implement testing around it yet.
nostrademons 8y ago
I think the point Waterluvian is making is that if a startup has all its development practices buttoned down right, it's either not a startup or it's going to go out of business soon. Most people (who are even thinking of working at a startup, at least) would rather have a job that's organized chaos than not have a job at all. The ideal order of tasks for a startup usually looks something like this (and I say "ideal" because very few startups actually take paths resembling anything close to this): 1.) Figure out what & for whom you're building the product. The founders should do this before hiring employees. 2.) Validate that the people for whom you're building the product will use it, and ideally will pay for it. The founders should do this before hiring employees. 3.) Take investment. Ideally this would get pushed as late as possible or skipped entirely, both because you get better terms for that money when you've made more progress and because it often comes with strings that prevent you from going back to step #1 if necessary, but it's usually a prerequisite for step #4. 4.) Build the product. If the founders can do this themselves, they're at a huge advantage, because oftentimes you find you need to go back to step #1 after this is complete. But usually you need employees for this. 5.) Charge money, so that it becomes a sustainable business. 6.) Everything else that goes with being an actual business, from getting HR policies right to development practices to career ladders for employees to working out company mission statements. And if you're doing step #6 before you've completed step #5, there is a very large chance that you've made a critical error in judgment that will kill the company. Why? Because you haven't actually validated step #1, and all the work in steps #4-6 depends upon getting that right. You might have setup a beautiful CI dashboard with 100% test coverage, only to find that all your unit tests & continuous integration need to be thrown out because your product needs to be rewritten in another language because the product concept requires a large & critical library that's only available in another language. You might have spent months developing & building relationships with employees only to find they need to be fired because you need a completely different skillset to build a different product for a different market. It's fine to want a nice, orderly, 100% tested with CI setup and a robust release process development process as your working environment. At an earlier point in my career, I certainly did. But if that's what you want, I would highly recommend not working at a startup and going to Google instead, where you have a full test suite run on 1000s of machines on every commit and the results of it are instantly visible on their code review dashboard. That's what I did, and it was only when I realized that Google in 1999 was about as far away from that as it's possible to get that I became more comfortable with the codebase being a complete mess as long as it works & has happy users.
- nine_k 8y ago
  This is very true. But setting up CI is a day's worth of work, and pays off almost immediately. Having reasonable logging in an app of any serious size is a cultural thing; it takes exactly as much time to write as bad logging, and saves oodles of time every day when you have to discover and fix issues. Compare it to building a motorbike. Yes, you want a prototype fast. But if you have all your tools stored as one big pile, or have oil and fuel spilled next to your welding machine, it does not speed you up; it sets you for an accident after accident.
  - nostrademons 8y ago
    The issue with all of these things is that in a startup you don't know what the expected behavior is. You only can find that out, for sure, by putting it in front of customers and having them pay you for it - which often requires building the product or at least some approximation of it first, and may need to be repeated dozens to hundreds of times before you find something that is a.) useful b.) worth paying for c.) can't be found cheaper elsewhere and d.) has a large enough market to be worth building. You can and should short-circuit some of this with non-code development (eg. talking to customers, putting mockups in front of them, getting sign-ups on a landing page, signing LOIs), but you never know for sure that your product is worth it until people give you money in exchange for using the product. Unit/acceptance/integration tests, if done right, capture requirements. They verify that the code does what it should do, and continues doing it even when changed. You can't write meaningful tests until you have some basic idea what the code should do - what would your expected results even be? Logging, if done right, is about being able to quickly answer questions about the operation of your system. You learn which questions to ask only through the experience of having people actually use it. Logging can easily tell you fine-grained details about how much wall-clock each phase of your program takes. Should it? Well, depends - if you're about to rip all the code out and rewrite it, or if it's just something that runs once to generate some data and never again, it doesn't matter if it's slow. Similarly, good logging can tell you precise details about how people are using the product. Should it? Here's a counterintuitive lesson learned the hard way: not until after you've answered the question of are people using the product. If you're getting a bounce rate of 100% (which you can determine by slapping Google Analytics on the front page), you need a completely different product concept, and it's a waste of time to instrument each user action with fine-grained logs until people are actually using it. You can always go back and add the logging then. A motorbike is a poor analogy. The consequences of failure for most tech startups are significantly less than the consequence of a motorbike crash, the software is a lot easier to change than motorbike parts, and the goal of what the software does is a lot more ambiguous than what a motorbike should do. Rather, I'd use the analogy of a novel. Your first draft of a novel is going to suck, it'll barely make sense, and the goal is just to get your thoughts down on paper. When you do revise it, you revise for plot & character first, then pacing and voice and realism and sensitivity, then you might clean up dialogue & wording, and only then do you look for typos. Why? Because there's no point in fixing typos for passages that are going to get ripped out and replaced anyway. Spelling and grammar is the part that everybody thinks of because it's the part everybody can do, but it's really the last part of putting together a finished story. Similarly, unit tests & CI & logging & one-click builds are the parts that everybody thinks of when they hear "development" because they're the parts that everybody should be able to do, but they're the last phase of building a worthwhile product. The first questions are "Who is using this? What are they trying to accomplish? How does it deliver value? How is it different from other alternatives available?"
reaperducer 8y ago
Proper logging doesn't take more time, it just takes more discipline / giving a damn. People and companies that say: we don't have time to do it right Almost always mean: we don't know how to do it right You're not wrong. But we're talking startups here, not established companies. It's publish or perish time. When the company has enough breathing room, circle back around and do it the way the big boys do.
- gnahckire 8y ago
  I disagree. Publish or perish includes time to triage issues, bugfixes, and new developer onboarding. If logging is fubar'd then all 3 of those are impacted. If you're pushing a PoC out the door. Sure, go on ahead and forgo proper logging. But if you're secured some form of series funding and need to scale. Fix your boat before you launch.
  - deleted 8y ago
    [deleted]
- lilbobbytables 8y ago
  Disagree here. You can go without lots of tooling and aim for simple and effective. You can even let in code that won't be perfect in the future (probably you'd be prematurely optimizing for the unknown future). But defensive programming will save you time. Non shitty logging takes minimal time, like, so minimal. It will make many bugs and customer issues trivial to fix. In the least, use something like Sentry. Makes up a lot for not logging because it adds the context with your uncaught exceptions.
- monksy 8y ago
  > circle back around and do it the way the big boys do. Things that never happen.
ionforce 8y ago
> Talent, not time, is the enemy of quality. What a refreshingly interesting perspective! How did you come upon this? Anyone care to disagree?
- latch 8y ago
  From experience. Not to beat a dead horse in this thread, but logging is still the simplest example to grasp. Good logging takes 0 extra time over bad logging, the only difference is talent. But you'll see this across the board. People who write well organized, readable, low coupled code do so naturally and at more or less the same speed as people who write piles of poo. They might both achieve the same functional output, but the clean code will pay dividends in the future (and not just long term, even next week when you have to make a little change) Also, quality is pretty core to a number key principle of the Toyota Production System (which many startups _attempt_ to emulate). Kaizen, muda and jidoka. Fred Brooks might have written "plan to throw one away; you will, anyhow." But he also wrote: "Study after study shows that the very best designers produce structures that are faster, smaller, simpler, clearer, and produced with less effort. The differences between the great and the average approach an order of magnitude. "
nikanj 8y ago
For the first year or so, the only way to get builds of our software was for me to click "build" in Visual Studio, on my laptop. I definitely knew how to set up a build server, CI pipeline, etc. It just would have meant that every time I (not we!) changed the build, I would have to fix my own machine and the pipeline. I'd much rather spend that time fixing one more issue, or adding one more feature. There are numerous things that increase velocity for a large team, but decrease it when the product is just getting started. Joel Spolsky wrote about something similar almost a decade ago, https://www.joelonsoftware.com/2009/09/23/the-duct-tape-programmer/ https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...
- Aeolun 8y ago
  If your CI breaks every time you change the build you are doing something wrong.
  - solomatov 8y ago
    It usually happens when tests are not fixed.
    - nikanj 8y ago
      It usually happens when changing the build means something like "Let's package the installers with WiX instead of NSIS, so we can provide MSIs for enterprise clients". Not everyone's app is a web page.
      - argyleaf 8y ago
        WiX is a nightmare from which I am feverishly trying to awake...
- nradov 8y ago
  That doesn't make any sense. Setting up the CI pipeline should be the first step, before writing any product code. It doesn't cost you any time, it saves time and allows for building more features faster.

by latch 8y ago

pmart123 8y ago

Maybe the context of the answer is more valuable than the answer in this case? i.e. we have 95% coverage on our core IP and CI setup for all of our source code. But, we integrated X for that service to get off the ground quickly, which will be too expensive at scale so we didn’t implement testing around it yet.

nostrademons 8y ago

I think the point Waterluvian is making is that if a startup has all its development practices buttoned down right, it's either not a startup or it's going to go out of business soon. Most people (who are even thinking of working at a startup, at least) would rather have a job that's organized chaos than not have a job at all. The ideal order of tasks for a startup usually looks something like this (and I say "ideal" because very few startups actually take paths resembling anything close to this): 1.) Figure out what & for whom you're building the product. The founders should do this before hiring employees. 2.) Validate that the people for whom you're building the product will use it, and ideally will pay for it. The founders should do this before hiring employees. 3.) Take investment. Ideally this would get pushed as late as possible or skipped entirely, both because you get better terms for that money when you've made more progress and because it often comes with strings that prevent you from going back to step #1 if necessary, but it's usually a prerequisite for step #4. 4.) Build the product. If the founders can do this themselves, they're at a huge advantage, because oftentimes you find you need to go back to step #1 after this is complete. But usually you need employees for this. 5.) Charge money, so that it becomes a sustainable business. 6.) Everything else that goes with being an actual business, from getting HR policies right to development practices to career ladders for employees to working out company mission statements. And if you're doing step #6 before you've completed step #5, there is a very large chance that you've made a critical error in judgment that will kill the company. Why? Because you haven't actually validated step #1, and all the work in steps #4-6 depends upon getting that right. You might have setup a beautiful CI dashboard with 100% test coverage, only to find that all your unit tests & continuous integration need to be thrown out because your product needs to be rewritten in another language because the product concept requires a large & critical library that's only available in another language. You might have spent months developing & building relationships with employees only to find they need to be fired because you need a completely different skillset to build a different product for a different market. It's fine to want a nice, orderly, 100% tested with CI setup and a robust release process development process as your working environment. At an earlier point in my career, I certainly did. But if that's what you want, I would highly recommend not working at a startup and going to Google instead, where you have a full test suite run on 1000s of machines on every commit and the results of it are instantly visible on their code review dashboard. That's what I did, and it was only when I realized that Google in 1999 was about as far away from that as it's possible to get that I became more comfortable with the codebase being a complete mess as long as it works & has happy users.

nine_k 8y ago
This is very true. But setting up CI is a day's worth of work, and pays off almost immediately. Having reasonable logging in an app of any serious size is a cultural thing; it takes exactly as much time to write as bad logging, and saves oodles of time every day when you have to discover and fix issues. Compare it to building a motorbike. Yes, you want a prototype fast. But if you have all your tools stored as one big pile, or have oil and fuel spilled next to your welding machine, it does not speed you up; it sets you for an accident after accident.
- nostrademons 8y ago
  The issue with all of these things is that in a startup you don't know what the expected behavior is. You only can find that out, for sure, by putting it in front of customers and having them pay you for it - which often requires building the product or at least some approximation of it first, and may need to be repeated dozens to hundreds of times before you find something that is a.) useful b.) worth paying for c.) can't be found cheaper elsewhere and d.) has a large enough market to be worth building. You can and should short-circuit some of this with non-code development (eg. talking to customers, putting mockups in front of them, getting sign-ups on a landing page, signing LOIs), but you never know for sure that your product is worth it until people give you money in exchange for using the product. Unit/acceptance/integration tests, if done right, capture requirements. They verify that the code does what it should do, and continues doing it even when changed. You can't write meaningful tests until you have some basic idea what the code should do - what would your expected results even be? Logging, if done right, is about being able to quickly answer questions about the operation of your system. You learn which questions to ask only through the experience of having people actually use it. Logging can easily tell you fine-grained details about how much wall-clock each phase of your program takes. Should it? Well, depends - if you're about to rip all the code out and rewrite it, or if it's just something that runs once to generate some data and never again, it doesn't matter if it's slow. Similarly, good logging can tell you precise details about how people are using the product. Should it? Here's a counterintuitive lesson learned the hard way: not until after you've answered the question of are people using the product. If you're getting a bounce rate of 100% (which you can determine by slapping Google Analytics on the front page), you need a completely different product concept, and it's a waste of time to instrument each user action with fine-grained logs until people are actually using it. You can always go back and add the logging then. A motorbike is a poor analogy. The consequences of failure for most tech startups are significantly less than the consequence of a motorbike crash, the software is a lot easier to change than motorbike parts, and the goal of what the software does is a lot more ambiguous than what a motorbike should do. Rather, I'd use the analogy of a novel. Your first draft of a novel is going to suck, it'll barely make sense, and the goal is just to get your thoughts down on paper. When you do revise it, you revise for plot & character first, then pacing and voice and realism and sensitivity, then you might clean up dialogue & wording, and only then do you look for typos. Why? Because there's no point in fixing typos for passages that are going to get ripped out and replaced anyway. Spelling and grammar is the part that everybody thinks of because it's the part everybody can do, but it's really the last part of putting together a finished story. Similarly, unit tests & CI & logging & one-click builds are the parts that everybody thinks of when they hear "development" because they're the parts that everybody should be able to do, but they're the last phase of building a worthwhile product. The first questions are "Who is using this? What are they trying to accomplish? How does it deliver value? How is it different from other alternatives available?"

reaperducer 8y ago

Proper logging doesn't take more time, it just takes more discipline / giving a damn. People and companies that say: we don't have time to do it right Almost always mean: we don't know how to do it right You're not wrong. But we're talking startups here, not established companies. It's publish or perish time. When the company has enough breathing room, circle back around and do it the way the big boys do.

gnahckire 8y ago
I disagree. Publish or perish includes time to triage issues, bugfixes, and new developer onboarding. If logging is fubar'd then all 3 of those are impacted. If you're pushing a PoC out the door. Sure, go on ahead and forgo proper logging. But if you're secured some form of series funding and need to scale. Fix your boat before you launch.
- deleted 8y ago
  [deleted]
lilbobbytables 8y ago
Disagree here. You can go without lots of tooling and aim for simple and effective. You can even let in code that won't be perfect in the future (probably you'd be prematurely optimizing for the unknown future). But defensive programming will save you time. Non shitty logging takes minimal time, like, so minimal. It will make many bugs and customer issues trivial to fix. In the least, use something like Sentry. Makes up a lot for not logging because it adds the context with your uncaught exceptions.
monksy 8y ago
> circle back around and do it the way the big boys do. Things that never happen.

ionforce 8y ago

> Talent, not time, is the enemy of quality. What a refreshingly interesting perspective! How did you come upon this? Anyone care to disagree?

latch 8y ago
From experience. Not to beat a dead horse in this thread, but logging is still the simplest example to grasp. Good logging takes 0 extra time over bad logging, the only difference is talent. But you'll see this across the board. People who write well organized, readable, low coupled code do so naturally and at more or less the same speed as people who write piles of poo. They might both achieve the same functional output, but the clean code will pay dividends in the future (and not just long term, even next week when you have to make a little change) Also, quality is pretty core to a number key principle of the Toyota Production System (which many startups _attempt_ to emulate). Kaizen, muda and jidoka. Fred Brooks might have written "plan to throw one away; you will, anyhow." But he also wrote: "Study after study shows that the very best designers produce structures that are faster, smaller, simpler, clearer, and produced with less effort. The differences between the great and the average approach an order of magnitude. "

nikanj 8y ago

For the first year or so, the only way to get builds of our software was for me to click "build" in Visual Studio, on my laptop. I definitely knew how to set up a build server, CI pipeline, etc. It just would have meant that every time I (not we!) changed the build, I would have to fix my own machine and the pipeline. I'd much rather spend that time fixing one more issue, or adding one more feature. There are numerous things that increase velocity for a large team, but decrease it when the product is just getting started. Joel Spolsky wrote about something similar almost a decade ago, https://www.joelonsoftware.com/2009/09/23/the-duct-tape-programmer/ https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...

Aeolun 8y ago
If your CI breaks every time you change the build you are doing something wrong.
- solomatov 8y ago
  It usually happens when tests are not fixed.
  - nikanj 8y ago
    It usually happens when changing the build means something like "Let's package the installers with WiX instead of NSIS, so we can provide MSIs for enterprise clients". Not everyone's app is a web page.
    - argyleaf 8y ago
      WiX is a nightmare from which I am feverishly trying to awake...
nradov 8y ago
That doesn't make any sense. Setting up the CI pipeline should be the first step, before writing any product code. It doesn't cost you any time, it saves time and allows for building more features faster.