looks be nice for critical files/directories.
Does it always require a manual check if the sizes do change, or does it allow to set a threshold like https://github.com/siddharthkp/bundlesize which auto-succeeds it the size diff is within it?
It does require manual approval for any new or growing files atm but adding some kind of setting for a threshold (maybe per file type) for which Gravity auto-approves might be a good addition in the future
I share learning and experiences from running simplabs as a full remote company for many years:
* remote work is about culture, not getting everyone on Slack
* transparency among the team is critical if you don't want to alienate team members (burn down your sticky-notes walls!)
* managers must have trust and give up on micro-management – just because they cannot see the work happening doesn't mean it is not happening
* remote work is great but there's no replacement for regularly meeting coworkers in-person (once that's possible again responsibly)
ShapeUp is great! I don't think a cool-down phase is good though – if something is important to someone and it is indeed important for the business but still doesn't get planned in any iterations that means either
a) it's not actually important compared to other things so having someone work on it in a cool down phase is likely not well-spent time
or
b) there is a dysfunctional team/organization in which important stuff doesn't get prioritized correctly (typical example for this being 100% product management driven organizations in which refactorings etc. never get any time assigned)
Hey, I’m the author. I think you Mis-interprete what I’m saying - of course understanding timelines and budget will often be a legitimate need of one or some stakeholders, among others. And of course making teams stick to deadlines when that’s not possible is bullshit. But the other extreme - demanding that nothing can ever be estimated and understood well up-front - is equally wrong. In the Limited scope of an iteration, it is well possible to reduce risk and uncertainty at least a good amount through thorough analysis and preparation.
I disagree, in my opinion it is never legitimate to pressure people into predicting the future, and it simply never works.
There is a very this counter-intuitive thing about predicting the future.
We tend to believe that by cutting our predictions in smaller and smaller pieces, our predictions will be closer to reality, or at least more manageable. But there is nothing further from the truth, the best predictions are made when someone experienced in the field is looking at the big picture and try to give a rough estimation.
This has been proven again and again.
At the end od the day, people are working and projects gets finished not because, but in spite of micro-management and other unhelpful practices.
Indeed we disagree. I’d say the reluctance that’s relatively wide spread in particularly among engineers to even try and reduce risk as much as possible (within a limited scope) and framing that as „predicting the future“ is a huge fallacy that doesn’t benefit anyone. There’s just not only the 2 extremes - completely and reliably predicting the future vs. just going off with no plan - but there’s something in the middle.
Also the big picture That one could look at in the beginning of a project and base an estimate on is more often than not not what you end up with at the end of the project anyway.
> On the other hand middle-management is always trying to push their peons to predict the future and accept the liability.
That's bad just middle management then though. It's also why I'm advocating against project managers who would typically/often/sometimes do what you describe here – if you have someone who doesn't actively contribute to the project influence (or dictate in the worst case) timelines, that's deemed to fail from the beginning.
There's a particular bit of wishful thinking endemic to software project managers, in particular: the belief that almost everything useful is also predictable, and that what's left accounts for only a tiny fraction of the overall effort. A bit of reflection should make it obvious that the opposite is true: if it was so easy, somebody else would have done it before. Yet, like every 15-year-old who believes in their heart that they'll grow up to be rich and famous, the manager always assumes that they're just the first person to think of cloning Facebook.
Bug bashes are a bit like cool down periods in my experience – if your focus is 100% on features all of the time then every now and then you need to catch up on open bugs or piled up tech debt. I'd argue these types of activities are not necessary at all when all stakeholders contribute to the scope of each iteration (see https://simplabs.com/blog/2020/06/17/failing-and-winning-at-...). Still, if a bug isn't taken on for x weeks or months, I'd say 99% of the time it never will be and can just as well be closed since it's ignored anyway.
Not maintaining a backlog doesn't necessarily mean you cannot collect ideas etc. anywhere. I think the two main points are:
* putting effort into preparing proper tickets for all these ideas is likely wasted time as 90% of the ideas will never be taken on
* keeping all the ideas together with the issues that are actually important creates noise and makes it harder to identify the actually important stuff; also having a backlog with thousands of open tickets puts loads of emotional pressure on teams since they are always feeling like they lack behind while in reality most of those thousands of tickets are irrelevant anyway.
Also I'm not sure what the point of being able to say
> "see, it still hardly ever happens, but here's another one".
would be really (except for being right about the existence of something) – if the decision is not to fix the bug it's irrelevant still.
Sure, you should have bugs documented somewhere but I'm not sure a bug that hasn't been fixed for x months needs to be there since it's a bug the team obviously decided not to care about.
I personally fixed bugs that have been opened for longer then that, so nope, they can get fixed. Plus, it prevents people from opening them again and again and again and again as they all notice the same thing.
I've fixed a couple Firefox bugs that were filed in Bugzilla 10-15 years ago. :)
At least one fix, however, upset some people who come to like the "incorrect" behavior over those 10-15 years. (In one case, I changed the filename of saved web pages from "index.html" to HTML <title> .html to match Chrome and IE behavior.)
Planning and estimating projects (or sprints within projects) is associated with a lot of uncertainty and frustration on all sides. At the same time, teams feel they have to adopt processes like Scrum (or their own interpretation of it) and then expect that to fix everything which is usually not the case of course. In reality what I find lacking in most teams is direct communication and close collaboration as well as an appreciation for the valid and reasonable needs and interests of each and every project stakeholder (that's not only engineering and design but also product, marketing, finance maybe etc.).
In this post, I present a set of relatively simple techniques to practice that remove a team's frustration and enable better estimates and predictability.
