4 ms·
Perhaps because first they had to fix their CI so they can fix their real problems. It's often underrated how much an otherwise competent team can crumble unde
by ithkuil 5y ago
Perhaps because first they had to fix their CI so they can fix their real problems.
It's often underrated how much an otherwise competent team can crumble under technical debt (of which CI and test flakiness is one specimen).
It sounds plausible to me that slack's rapid growth curve put them in the perfect position to accrue massive amounts of debt from which they are struggling to wade their way through.
- ilrwbwrkhv 5y agoThis is such a hard one. How do you do this as a startup. How do you keep delivering features fast without accruing crazy amounts of debt? Does it boil down to the quality and experience of the hackers on the team?
- nanis 5y ago> Does it boil down to the quality and experience of the hackers on the team? Yes. But also requires management who can understand and value what they have in that team.
- dwohnitmok 5y agoI think one good threshold for most startups is product-market fit. Before you have it, you should be willing to accumulate large amounts of tech debt both because your product might change enough that you'd be rapidly throwing out large amounts of code anyways and because having product-market fit is such an overwhelming need that almost everything should be traded against it because your startup is dead without it. After you have it, you have to be much more diligent about paying down tech debt, because you switch from a more "exploratory" mode to a "refinement" mode where you now are unlikely to be throwing away large swaths of your code at the drop of a hat, and instead need to iteratively build upon what you already have and that becomes very difficult to do with large amounts of tech debt.
- jrockway 5y agoI think engineers are super bad at deciding where to take on technical debt. Often people will save themselves half a day at the cost of making some future feature nearly impossible. I don't really blame the engineers, but rather the system -- the customers demand new things, then there are biweekly "sprints" to set deadlines, and there are daily standups where nobody wants to say "I'm doing the same thing I did yesterday and it's not done yet." In that system, saving five minutes at any cost is the right thing to do, and then you get boiled alive by your technical debt. I honestly think that the glacial pace of software engineering is mostly due to this phenomenon -- "where can we save a little bit of time today?" and then it snowballs into entire teams not getting anything done. The interest on the loan they took out is higher than their income. I guess that's why they call it technical debt. (Does that make Scrum Masters technical loan sharks?)
- dboreham 5y agoYou can tell that this is occurring because you'll never hear someone say at the standup "I got nothing done since the last standup because [yarn|sbt|cargo] blew up spectacularly and I spent two days figuring out what was happening and that I had to revert to the previous point release that still works".
- steveBK123 5y agoI think management induced agile/standups are there to produce this outcome. If your boss wants to see/hear daily updates, they don't want to see daily reports of non-progress. Developers who don't get that intuitively quickly learn it when they get the wrong type of questions after the wrong type of updates. Tail wagging the dog.
- Akronymus 5y agoChoose a better tech stack IMO. One that facilitates the pits of success rather than pits of failure. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html