8 ms·

Yes but quality, naturally enough, takes more time. And while this might be great for organizations with plenty of buffer, for any start-up it has to be that "g

Yes but quality, naturally enough, takes more time. And while this might be great for organizations with plenty of buffer, for any start-up it has to be that "good today beats perfect tomorrow".

dagss 4y ago
Buggy code can be a real timesink for startups...the failures often cannot be ignored too long, they just sit and mature and compound some interest before they have to be fixed anyway. And writing bug free/low bug code is about experience level and how your development methodology is -- not about spending more wall clock time. (I.e. for the quality you may spend more on salaries per hour, but not more hours -- probably a very good idea for a startup IMO) I believe that in many situations high quality code is a LOWER net investment than low quality code.
- leetrout 4y ago
  I think this captures my experiences perfectly. Building something the right way usually means it runs better with much lower maintenance overhead and is easier to extend or replace later.
- dhzhzjsbevs 4y ago
  > I believe that in many situations high quality code is a LOWER net investment than low quality code. This statement requires one caveat: your codebase sunset date. Without it you can justify basically anything on the quality slider.
  - dagss 4y ago
    I meant in the context of 2-3 years before a rewrite I guess. Code with bugs can just sink your team in the first months after hitting production..
dhzhzjsbevs 4y ago
There is a difference between quality and overengineered features nobody asked for. Nobody is suggesting we "do everything in the ideal way". We're suggesting taking 5 minutes to think about the thing you're writing in the next 30. It produces less buggy code, and likely, be able to complete the task with less iteration because you made the mistakes in your head and changed plans before you wrote them out. I close out 30 tickets a week, other teams at our company are lucky if they close out that many as a team. I'm not trading quantity for quality at all, I'm simply choosing to do the things that matter and I ignore everything else.

Yes but quality, naturally enough, takes more time. And while this might be great for organizations with plenty of buffer, for any start-up it has to be that "good today beats perfect tomorrow".

dagss 4y ago

Buggy code can be a real timesink for startups...the failures often cannot be ignored too long, they just sit and mature and compound some interest before they have to be fixed anyway. And writing bug free/low bug code is about experience level and how your development methodology is -- not about spending more wall clock time. (I.e. for the quality you may spend more on salaries per hour, but not more hours -- probably a very good idea for a startup IMO) I believe that in many situations high quality code is a LOWER net investment than low quality code.

leetrout 4y ago
I think this captures my experiences perfectly. Building something the right way usually means it runs better with much lower maintenance overhead and is easier to extend or replace later.
dhzhzjsbevs 4y ago
> I believe that in many situations high quality code is a LOWER net investment than low quality code. This statement requires one caveat: your codebase sunset date. Without it you can justify basically anything on the quality slider.
- dagss 4y ago
  I meant in the context of 2-3 years before a rewrite I guess. Code with bugs can just sink your team in the first months after hitting production..

dhzhzjsbevs 4y ago

There is a difference between quality and overengineered features nobody asked for. Nobody is suggesting we "do everything in the ideal way". We're suggesting taking 5 minutes to think about the thing you're writing in the next 30. It produces less buggy code, and likely, be able to complete the task with less iteration because you made the mistakes in your head and changed plans before you wrote them out. I close out 30 tickets a week, other teams at our company are lucky if they close out that many as a team. I'm not trading quantity for quality at all, I'm simply choosing to do the things that matter and I ignore everything else.