91–100 of 183 posts
Here's the thing: I know of at least one company that made it big starting with a steaming pile of technical garbage. They used their users as a QA department. The business logic was all in stored procedures in the DB, which was always on fire as a result, and the front-end was bad PHP with so much indentation that it was 25% blank space after rendering the page! Yet their users loved them, the numbers went up and up…
Never forget that your startup customers aren't buying your code. They're paying for whatever the product does for them. They don't care if the code is good or bad, as long as the app does what they need it to do and does it well. So to answer your question: The code should be bad enough that it allows you to ship as fast as possible, but not so bad that the app doesn't work properly. This can be a shock if you've be…
Never forget that your startup customers aren't buying your code. They're paying for whatever the product does for them. They don't care if the code is good or bad, as long as the app does what they need it to do and does it well. So to answer your question: The code should be bad enough that it allows you to ship as fast as possible, but not so bad that the app doesn't work properly. This can be a shock if you've be…
"However, startups don't fail because the codebase is ugly, or convoluted, or not following best practices." Yes, they do. The obvious one is one senior developer who writes a bunch of trash code to get stuff done in a hurry. Later is asked to maintain it and add features. But it's no fun cause it's a pile of poo. New shiny attracts his attention and he moves on (cause, you know, he delivered at his current job!). Ne…
I feel like people walk through hypotheticals like that, but I've not heard people say "Company X failed because of that scenario."
In my experience, "code quality" vs "features" is simply not a real tradeoff. Writing clean code with tests, function documentation, a good level of modularity, automated deployments... etc will save you time in the short term . It's pretty simple: 1. Writing quality code is not substantially slower in the first place, especially when you factor in debugging time. You just have to have the right habits from the get-g…
Earlier quoted context omitted.
"The code should be bad enough that it allows you to ship as fast as possible" - I agree with the sentiment here, but not the expression. Speed and "validation" is obviously the outcome, and the ends should justify the means. But to say that fast must necessarily equal "bad" I'm not really sold on. Coupling is an obvious example. If you want to retain agility in your product, the various components inside should be p…
In the beginning architecture tends to be a form of procrastination for many people. IMO, when you have clear goals for improvement you should aim for somewhat worse than acceptable quality. Not because that’s the most efficient option, but because it for forces you to be solving customer problems. That itch to improve things is more focused when revising whatever is the worst parts of the entire project rather than…
I'd argue that the difference in time of writing tests is balanced by less time debugging, and the moment you want to re-use the code you know it already works in all the contexts the tests use it in, in fact it was already designed for re-use because the tests and the application use it, so you avoid major refactoring and instead just assemble your Lego blocks in a different shape.
Never forget that your startup customers aren't buying your code. They're paying for whatever the product does for them. They don't care if the code is good or bad, as long as the app does what they need it to do and does it well. So to answer your question: The code should be bad enough that it allows you to ship as fast as possible, but not so bad that the app doesn't work properly. This can be a shock if you've be…
> However, startups don't fail because the codebase is ugly, or convoluted, or not following best practices. Startups do fail due to a failure to execute. Best practices aren't always about aesthetics. Ignore them too much and you end up with write-only code. You can compensate in various ways, such as designing the code so that it's possible to throw away the ugly parts later. You are correct that good senior engine…
It seemed like static typing, "find all references" and the limited use of reflection style coding made the difference between bad code being annoying and completely unworkable.
The more specific an outcome you're looking for the more factors you'll have to consider. You can loosely think of the relationship between code and companies like the code is "the matrix" and the tangible business world is "the real world". It might help to think of the code as a child being raised in the matrix.
The first product market fit stage is the hardest. Here it befits the code to be maximally extensible such that you can most effectively steer it around the market landscape and most effectively capitalize on any discoveries made. But you also need it to work decently enough to have traction. This stage is like parenting a baby that needs to decide its life mission and begin it during the first few years of its life. Its main purpose is self-discovery, but also it needs to be set up to become whatever it discovers it wants to be. Here, luck is the main name of the game.
The next stage is growth (farming the land you've staked, becoming the thing you've decided your codebase baby's life is about). Here you need less extensibility and more fidelity. You're clear on what your code needs to do, and you just need to make sure you do it well enough to last long term. But also things get more complicated at the org level. Now a team has to be built out. The codebase must now mature, and that means that it must gain a firmer grasp on its purpose (high fidelity architecture and infrastructure) and learn to interface with the world (be geared towards long-term maintainability).
After you exit that stage, you exit the startup stage entirely. Generally, if you're a businessperson and it's available to you, having good engineers (human communication skills above technical skills, understand the holistic function of engineering within the context of the rest of the company) is the best solve to this problem. They will have the vision to assess the field and the communication skills to inform you about it.
You will feel the urge to carve the unpredictability of the outcome down with measurements, metrics, and calculations but this is mostly a fool's errand. If you're doing something brand new there is no defined path and it is about pathfinding, not measuring your performance along a path. There are a ton of resources that all give opinion on the best way through this beginning patch of woods, but the true reality is that at the end of the day, getting through woods that no one has ever gotten through is something that can only be mapped in hindsight.
Never forget that your startup customers aren't buying your code. They're paying for whatever the product does for them. They don't care if the code is good or bad, as long as the app does what they need it to do and does it well. So to answer your question: The code should be bad enough that it allows you to ship as fast as possible, but not so bad that the app doesn't work properly. This can be a shock if you've be…
"However, startups don't fail because the codebase is ugly, or convoluted, or not following best practices." Yes, they do. The obvious one is one senior developer who writes a bunch of trash code to get stuff done in a hurry. Later is asked to maintain it and add features. But it's no fun cause it's a pile of poo. New shiny attracts his attention and he moves on (cause, you know, he delivered at his current job!). Ne…
In my case this was a relatively mature company on a version 2 reimplementation of an existing product, so it wasn't a complete death sentence. It eventually led to a complete house cleaning of CTO and product management in the end though. But, the company sure didn't fail!
1.) What market are you targeting and what are the overall user expectations for features, quality, reliability, etc.?
2.) What is the minimum viable feature set (i.e., product) to get into that market?
3.) Is it more important to be fast to market or the best to market?
Products are built iteratively. Even if it's OK to deliver on the fast and crappy model you still need a path to fix things incrementally. This applies to just about every product I've ever seen.
In my experience, "code quality" vs "features" is simply not a real tradeoff. Writing clean code with tests, function documentation, a good level of modularity, automated deployments... etc will save you time in the short term . It's pretty simple: 1. Writing quality code is not substantially slower in the first place, especially when you factor in debugging time. You just have to have the right habits from the get-g…