4 ms·

Loved this read. One part didn’t resonate with me though: > In practice this lead to GitLab building many features over the years that just weren't useful: a

Loved this read. One part didn’t resonate with me though: > In practice this lead to GitLab building many features over the years that just weren't useful: a serverless platform nobody asked for and that was ultimately killed off, support for managing Kubernetes clusters that didn't work for three weeks without anybody noticing, a chatops solution we had to build on top of our CI offering (thus introducing significant latency) instead of using existing solutions, or a requirements management feature that only supported creating and viewing data (not even updating or deleting); these are just a few examples from recent years. If my company ever grows to be as successful as Gitlab, I’m going to much more worried about innovation grinding to a halt than about people trying stuff that doesn’t work, or trying stuff the wrong way. It’s so much easier to shoot an idea down than to believe in it long enough for it to have a chance. I strongly agree with the author about making engineers be the decision makers on how to build out an engineering product, but I’m not convinced that this list of failed ideas is a bad sign at all.

pgeorgi 3y ago
It's a matter of focus: Having some time to tinker and try out stuff that might just fail is great. If it consumes so much development time that the must-haves deteoriate, you let down your customers.
aragilar 3y ago
I think it's less innovation and more failing to understand the requirements (i.e. only implementing half of what's needed, and then moving to the next thing). E.g. adding labels to gmail, but no way to have filters, so you have to manually apply them.
- Aeolun 3y ago
  Yeah, some of Gitlab’s features are hilariously half assed. Of the ‘one crud form but missing the delete and update part’ level.
ehmc 3y ago
This part of the article resonated with me, as I used to work as a tech lead for a very similar startup to Gitlab. We were always pushed to "ship MVP's" and "move fast and break things" by product and design, which always resulted in a half-broken features getting pushed to production and left there once the sprint was over. This also led to a constant inexorable growth of tech debt, that made me feel like we'd never be able to get things remotely stable in our corner of the product. I've since come to the conclusion that it's much better to build small, flexible, feature-complete systems that can be used for multiple iterations of ideas.
fireflash38 3y ago
If the failed ideas aren't then purged, then they become problems. And maybe they cause problems when implementing them too.

pgeorgi 3y ago

It's a matter of focus: Having some time to tinker and try out stuff that might just fail is great. If it consumes so much development time that the must-haves deteoriate, you let down your customers.

aragilar 3y ago

I think it's less innovation and more failing to understand the requirements (i.e. only implementing half of what's needed, and then moving to the next thing). E.g. adding labels to gmail, but no way to have filters, so you have to manually apply them.

Aeolun 3y ago
Yeah, some of Gitlab’s features are hilariously half assed. Of the ‘one crud form but missing the delete and update part’ level.

ehmc 3y ago

This part of the article resonated with me, as I used to work as a tech lead for a very similar startup to Gitlab. We were always pushed to "ship MVP's" and "move fast and break things" by product and design, which always resulted in a half-broken features getting pushed to production and left there once the sprint was over. This also led to a constant inexorable growth of tech debt, that made me feel like we'd never be able to get things remotely stable in our corner of the product. I've since come to the conclusion that it's much better to build small, flexible, feature-complete systems that can be used for multiple iterations of ideas.

fireflash38 3y ago

If the failed ideas aren't then purged, then they become problems. And maybe they cause problems when implementing them too.