21–30 of 93 posts
If something isn’t making for example the cost of a fulltime salary in revenue then the last 1% is a waste of time.
Revenue is not the only metric to consider IMHO.
Internal (maintenance) documentation
External (how-to/FAQ) documentation
Performance metric instrumentation
Easy-to-decipher performance metric dashboard
Usage metric instrumentation
Easy-to-decipher usage metric dashboard
Error metric instrumentation
Easy-to-decipher error metric dashboard
Alerting
Automated testing
None of the above are even important in launching a product, much less an MVP.
Startups have raised hundreds of millions and get millions of users without any of those. In fact they'd probably just slowed them down.
I will do these for myself and my team but only if management recognizes this as work. If my performance review comes back with a low rating despite me having done this work, I am not going to do this any longer. Management can feel free to deal with consequences.
Good software developers do know the benefit of those things. They resist the management's efforts to ignore those things. In the end, the software developer often give in because they know who has the power.
There's balance to be had, and cases where's it's not worth it to put in more effort on certain things... but the boss rarely has any visibility into the tech side of things.
Earlier quoted context omitted.
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 awa…
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.
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.
None of those things are going to make a bad feature successful and not doing these will not make a good feature unsuccessful. They're all a form of technical debt that should be used very sparingly. Some of them will be more of a distraction than they're worth. Somewhere around 2010 a sort of product development pseudo-science started to take hold of the industry. Telemetry, A/B testing, surveys... oceans began to b…
Earlier quoted context omitted.
intuitively i agree with you, i've seen a lot of the pseudo-science. But curious, can you elaborate on how telemetry driven development leads to organizational turf wars? I think i've seen that too but interested to hear your thoughts.
Everything from what gets tracked to how the data gets interpreted. It also can put a target on certain growth areas that will attract the more "ambitious" people from the company. All will try to make the case with the telemetry data. Does more time on a page mean users are more engaged or are they struggling to find out what's going on? Depends on which product manager can make a better case, probably involving eve…
None of those things are going to make a bad feature successful and not doing these will not make a good feature unsuccessful. They're all a form of technical debt that should be used very sparingly. Some of them will be more of a distraction than they're worth. Somewhere around 2010 a sort of product development pseudo-science started to take hold of the industry. Telemetry, A/B testing, surveys... oceans began to b…
Which is why the article says: "This last 1% isn't just what separates a great product from a good product, it's what separates a product that might not eventually fail from one that will eventually fail."
A feature can easily be successful while being impossible to maintain because when it comes time to pay the cost, all the main people involved have already claimed the required benefits and jumped ship.
Earlier quoted context omitted.
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 awa…
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.
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 de…