11–20 of 30 posts
Something I learned over the years... if your code quality is too high, it means you're sacrificing productivity.
Something I learned over the years... if your code quality is too high, it means you're sacrificing productivity.
Waiting for quality for release is always a mistake.
Release, refine and re-release. And A/B test, run the funnels and measure change as it happens.
Productivity on day #1 with bad code is a technical debt you take up - it will catch up to you if you ignore it for too long.
The day your app goes viral is not the day you want to learn about db sharding and data-architectures.
You'll want to grab all the users and keep them instead of 503'ing.
But if you do get past that phase, you can hire people like me to redo things and replace the bubblegum/fishing-line architecture with something more robust :)
Just wanted to add another view on this: wasting a few days creating a perfect design for something that you never even create is not necessarily wasted time. During that time you're thinking through all the different interactions your product could have and getting experience on putting together a good design for when you do need one. It's pretty good training and you learn the same whether you wasted the time or no…
Something I learned over the years... if your code quality is too high, it means you're sacrificing productivity.
The far more likely case is that your code quality is too low, which means you're sacrificing untold amounts of productivity later on. Well-written, self-explanatory code is a piece of cake for later developers to modify. Code repetition and counterintuitive naming has a good chance of wasting other people's time for no reason (if it doesn't bite you personally). In larger enterprises and startups alike, I suspect more productivity is lost revisiting badly-documented hacks than doing gold-plated "elegant" work for the first time.
Something I learned over the years... if your code quality is too high, it means you're sacrificing productivity.
In the initial stages of a product lifetime, you shouldn't focus on code quality. Releasing a crappy product beats waiting until it is well polished before releasing it, every single time.
But you should absolutely work on replacing, refining or polishing the crappy parts that turn out to be actually successful, or you'll end up in a dead end where you can't make your product evolve anymore without breaking everything. Or you'll get hit by the 'unlikely to be exploitable and difficult to fix' security flaws.
Crappy alpha code is good. Crappy legacy code, not so much.
Something I learned over the years... if your code quality is too high, it means you're sacrificing productivity.
I couldn't disagree with this sentiment more. Of course, it depends on your definition of quality, but for the sake of argument I'm assuming that we're including things like test coverage, code complexity, code cleanliness/readability, structural soundness (cohesion over coupling, the single reponsibility principle etc) and so on. The point with all of these things is that as much as they might seem to be a waste of…
For example, do you really need 100% unit test coverage of all corner cases?
Something I learned over the years... if your code quality is too high, it means you're sacrificing productivity.
However, if you're writing katamari code (that is, a tangled ball of garbage), you're sacrificing long term productivity. It seems like most people definitely don't err on the side of too high quality.
I'm just arguing against the case I've heard from many programmers that better code is always better. At a certain point, you hit diminishing returns and lose sight of the goal.
In the end when I read "Combatting Fake Progress" it sound so real. It seems that so many companies are trapped in real bondages and they just seems to be running without any kind of plans.