5 ms·

All of those things should be added. I would argue they take far more than 1%. They're easily 10, 20 maybe 30 or 40% of the work. Creating robust dashboards, al

All of those things should be added. I would argue they take far more than 1%. They're easily 10, 20 maybe 30 or 40% of the work. Creating robust dashboards, alerting and documenting the work in an externally digestible and internally debuggable format is very time consuming and difficult work that pays dividends when done but often gets thrown out because we schedule our work for 'MVP and yeet' where 'minimum' is defined as 'minimum to click button', not 'minimum to support button'.

baal80spam 3y ago
Not to mention a good AT coverage - it can easily take 20% of project time, and often much more.
- huganabaga 3y ago
  But it saves heaps of work after. Far beyond 20%. (The projects I work on typically spend over 50% on automated tests, but I'm in an area of the software industry where we really can't have and bugs escape into the wild. I wish more areas would work like that.)
lumost 3y ago
Having worked in multiple environments with differing code quality standards, it's pretty apparent how both "minimum and yeet" and "completion or bust" fail. "Minimum and yeet" works surprisingly well if you have unsolvable debates on customer value, options to yank the feature if it sucks, and generally competent engineers. If you are really good at yanking the feature when it sucks - you may even be able to get away with incompetent engineers. However if you repeat this cycle on the same code base 100x over, every feature gets harder. Eventually you hit a point where no one really knows how to do anything anymore as a feature that used to take 2 weeks now takes 8 months. "Completion or bust" works really well when you can't take a feature back... ever. However the definition of completion tends to grow over time. I've seen launch checklists which amounted to 6 month projects on their own (for both good and bad reasons). Sometimes completion becomes an excuse for architectural astronauts to enforce a change resistant paradigm on the code, eliminating any gains from completionism. Other times, the engineers and managers become convinced that any change will take N months and start ignoring everything that doesn't look like it will provide N months of value. In an ideal world, I'd love to see organizations better adapt their standards to the needs of individual teams or invest in tooling which makes it "cheap" to do the right thing. However this is not easy to pull off.
- t-writescode 3y ago
  I love this whole post! Small add: "generally competent engineers" can sometimes (almost) inline most of the code completeness details for cheap, reducing their cost greatly. Writing documentation is always a time sink, though, in my experience. Or maybe I'm just not good at it :P It's usually an additional day of work overall, though.
  - tracker1 3y ago
    Depends on what you're doing... For a developer focused documentation, I often will write a bit of the documentation up front as a project is getting setup with the intent on how it should work locally (or per developer). Then fill in details as each part gets more flushed out. Same for library APIs, command-line scripts/tools etc. For end-user products with a user interface, less so as it comes down to being flexible... similar with dashboards, as a developer I often don't know what is wanted up front... when something is asked for and you learn the domain more, it can come together easier. Larger projects with a front end component and many developers, nearly have to forget it at the dev level.
  - Spellinator 3y ago
    Writing docs, especially detailed and complete, can really save you in the long run. Plus the people that come after you will greatly appreciate your efforts.
  - huganabaga 3y ago
    > Writing documentation is always a time sink, though, in my experience. Or maybe I'm just not good at it :P It's usually an additional day of work overall, though. And it saves you days and days of re-discovering truths about your code weeks/months/years down the line. Sometimes those rediscovered facts are not even true which will come bite you big time. Integrate your documentation with your testing. That makes it easier to create and maintain. You don't have comprehensive automatic tests? Then that's your problem right there.
    - t-writescode 3y ago
_a_a_a_ 3y ago
Documentation is a deliverable as much as software. Just as important too.
hackernewds 3y ago
> Creating robust dashboards, alerting and documenting the work in an externally digestible and internally debuggable format is very time consuming and difficult work that pays dividends This is why having a solid BI and Data science org is underrated. To assign these to eng teams is disparaging for every org.

baal80spam 3y ago

Not to mention a good AT coverage - it can easily take 20% of project time, and often much more.

huganabaga 3y ago
But it saves heaps of work after. Far beyond 20%. (The projects I work on typically spend over 50% on automated tests, but I'm in an area of the software industry where we really can't have and bugs escape into the wild. I wish more areas would work like that.)

lumost 3y ago

Having worked in multiple environments with differing code quality standards, it's pretty apparent how both "minimum and yeet" and "completion or bust" fail. "Minimum and yeet" works surprisingly well if you have unsolvable debates on customer value, options to yank the feature if it sucks, and generally competent engineers. If you are really good at yanking the feature when it sucks - you may even be able to get away with incompetent engineers. However if you repeat this cycle on the same code base 100x over, every feature gets harder. Eventually you hit a point where no one really knows how to do anything anymore as a feature that used to take 2 weeks now takes 8 months. "Completion or bust" works really well when you can't take a feature back... ever. However the definition of completion tends to grow over time. I've seen launch checklists which amounted to 6 month projects on their own (for both good and bad reasons). Sometimes completion becomes an excuse for architectural astronauts to enforce a change resistant paradigm on the code, eliminating any gains from completionism. Other times, the engineers and managers become convinced that any change will take N months and start ignoring everything that doesn't look like it will provide N months of value. In an ideal world, I'd love to see organizations better adapt their standards to the needs of individual teams or invest in tooling which makes it "cheap" to do the right thing. However this is not easy to pull off.

t-writescode 3y ago
I love this whole post! Small add: "generally competent engineers" can sometimes (almost) inline most of the code completeness details for cheap, reducing their cost greatly. Writing documentation is always a time sink, though, in my experience. Or maybe I'm just not good at it :P It's usually an additional day of work overall, though.
- tracker1 3y ago
  Depends on what you're doing... For a developer focused documentation, I often will write a bit of the documentation up front as a project is getting setup with the intent on how it should work locally (or per developer). Then fill in details as each part gets more flushed out. Same for library APIs, command-line scripts/tools etc. For end-user products with a user interface, less so as it comes down to being flexible... similar with dashboards, as a developer I often don't know what is wanted up front... when something is asked for and you learn the domain more, it can come together easier. Larger projects with a front end component and many developers, nearly have to forget it at the dev level.
- Spellinator 3y ago
  Writing docs, especially detailed and complete, can really save you in the long run. Plus the people that come after you will greatly appreciate your efforts.
- huganabaga 3y ago
  > Writing documentation is always a time sink, though, in my experience. Or maybe I'm just not good at it :P It's usually an additional day of work overall, though. And it saves you days and days of re-discovering truths about your code weeks/months/years down the line. Sometimes those rediscovered facts are not even true which will come bite you big time. Integrate your documentation with your testing. That makes it easier to create and maintain. You don't have comprehensive automatic tests? Then that's your problem right there.
  - t-writescode 3y ago

_a_a_a_ 3y ago

Documentation is a deliverable as much as software. Just as important too.

hackernewds 3y ago

> Creating robust dashboards, alerting and documenting the work in an externally digestible and internally debuggable format is very time consuming and difficult work that pays dividends This is why having a solid BI and Data science org is underrated. To assign these to eng teams is disparaging for every org.