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
we don't know how to do it right
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.
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-prog...
Maybe, if I were executing on someone else’s vision, I could justify taking time up front to set up CI. But I still think it’s a little dogmatic to state that this has to be the first order of business, always.
>> numerous things that increase velocity for a large team, but decrease it when the product is just getting started.
Irrespective of the team size, if the speed of delivery has to grow, a decent CI/CD helps make it faster, IMO.
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.
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.
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.
Things that never happen.
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.
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.
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?"
The point is that in a tech startup, you are attempting to solve a previously unsolved problem. If the problem has already been solved before, why shouldn't your customers just use the existing solution? And there's a generic set of best practices for startup coding, but it basically amounts to "Do absolutely nothing that doesn't help you validate the key unknowns of your business hypothesis." Basically if you know that something is going to work, you shouldn't be doing it - you should be integrating the library/service/tool that already does it, or hiring the person that's done it before.
What a refreshingly interesting perspective!
How did you come upon this?
Anyone care to disagree?
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. "
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.