Regarding comments, I've always taught my juniors that in most cases, you comment to explain why something is done, not what it does. What the code does should be relatively self explanatory unless it's a very complex algorithm.
We really need a more common process other than Scrum/Agile. Nowadays it feels that it’s either Agile or Waterfall, no other alternatives in that market that people trust. Agile is really flawed in some ways and is not for all engineering teams.
I’ve heard a lot of positive feedback from teams using ShapeUp. Hope it’s something that can be widely adopted as well!
Regarding comments, think in abstraction levels. If the comment is at the same abstraction level as the code, then the code sucks. Comments at a higher abstraction level can be extremely useful.
"Dogma: 2-4 week sprints are how modern teams work"
"I believe that sprints are taking the joy out of building software."
"Shape Up is a great alternative."
Working in sprints is, indeed, a common dogma. It's easy to track how it took root (Scrum/Agile). It was never a native way of working for engineering teams. Yet, it was a huge improvement over what we had before (1-2 a year big-ass release, with a lengthy and painful stabilization period toward the end of the timeline).
Interestingly, by 2010, we already had a better alternative, which was a flow-based approach (Kanban/Lean-inspired). It both reflected a natural flow of engineering work better *and* doubled down on frequent delivery of value.
Mechanically, one could think about it as making sprints shorter and shorter up to a point where the iteration length is impractical to synchronize across the whole team, so it loses the meaning altogether.
What 37signals/Basecamp did with ShapeUp was just an attempt to repackage Scrum into something that fit their operations better. There's no universally valid argument why a 6-week sprint is better than a 2-week sprint. Both are artificial constructs aiming to organize work in a specific way that, in one context, may be fitting, while in another, it will not be so.
From a systems-thinking and flow perspective, the change suggested by ShapeUp is actually for the worse. (Note: I don't argue that it may be better for some people's comfort, but that's not how we optimize effectiveness.)
So, for anyone who thinks that sprints are not that good a choice, I'm with you. You can ditch them altogether. We've had better alternatives for almost 20 years.
Oh, and changing one type of sprint to another may not be the solution you're looking for. Even if the latter was backed by DHH.
I think Basecamp doesn't say anywhere ShapeUp is the right fit for every company - what I mainly liked is that they actually took to experimnation, and honed in their own approach, that works well for them.
I guess no one ever said that [their method] is the right fit for every company :)
Don't get me wrong, I support your message in the entire article. It's just this small bit has stricken me as odd. "I don't like iterations. Here's a good alternative: iterations, but slighly longer."
Admittedly, I have some bias against DHH. I appreciate his contributions to software development. However, when we wanders into theory of management or theory of work, it's like a celebrity offering advice on medicine.
It will be heard, that's for sure. The question is whether it's any good. And if you ask people who studied the matter (in this case management theory or flow), well, as fun as ShapeUp or Rework sounds, don't bet too much on those.
Regarding comments, I've always taught my juniors that in most cases, you comment to explain why something is done, not what it does. What the code does should be relatively self explanatory unless it's a very complex algorithm.
We really need a more common process other than Scrum/Agile. Nowadays it feels that it’s either Agile or Waterfall, no other alternatives in that market that people trust. Agile is really flawed in some ways and is not for all engineering teams.
I’ve heard a lot of positive feedback from teams using ShapeUp. Hope it’s something that can be widely adopted as well!
Planning to share an experience from another team soon, and also started to play with Shape Up myself :)
Great post!
Strong agree, especially on sprints. Check out: https://newsletter.pragmaticengineer.com/p/project-management-in-tech
Regarding comments, think in abstraction levels. If the comment is at the same abstraction level as the code, then the code sucks. Comments at a higher abstraction level can be extremely useful.
Thanks for the reference, it was a great read!
And I fully agree about the abstraction level
"Dogma: 2-4 week sprints are how modern teams work"
"I believe that sprints are taking the joy out of building software."
"Shape Up is a great alternative."
Working in sprints is, indeed, a common dogma. It's easy to track how it took root (Scrum/Agile). It was never a native way of working for engineering teams. Yet, it was a huge improvement over what we had before (1-2 a year big-ass release, with a lengthy and painful stabilization period toward the end of the timeline).
Interestingly, by 2010, we already had a better alternative, which was a flow-based approach (Kanban/Lean-inspired). It both reflected a natural flow of engineering work better *and* doubled down on frequent delivery of value.
Mechanically, one could think about it as making sprints shorter and shorter up to a point where the iteration length is impractical to synchronize across the whole team, so it loses the meaning altogether.
What 37signals/Basecamp did with ShapeUp was just an attempt to repackage Scrum into something that fit their operations better. There's no universally valid argument why a 6-week sprint is better than a 2-week sprint. Both are artificial constructs aiming to organize work in a specific way that, in one context, may be fitting, while in another, it will not be so.
From a systems-thinking and flow perspective, the change suggested by ShapeUp is actually for the worse. (Note: I don't argue that it may be better for some people's comfort, but that's not how we optimize effectiveness.)
So, for anyone who thinks that sprints are not that good a choice, I'm with you. You can ditch them altogether. We've had better alternatives for almost 20 years.
Oh, and changing one type of sprint to another may not be the solution you're looking for. Even if the latter was backed by DHH.
I think Basecamp doesn't say anywhere ShapeUp is the right fit for every company - what I mainly liked is that they actually took to experimnation, and honed in their own approach, that works well for them.
And that is my main point in all the dogmas :)
I guess no one ever said that [their method] is the right fit for every company :)
Don't get me wrong, I support your message in the entire article. It's just this small bit has stricken me as odd. "I don't like iterations. Here's a good alternative: iterations, but slighly longer."
Admittedly, I have some bias against DHH. I appreciate his contributions to software development. However, when we wanders into theory of management or theory of work, it's like a celebrity offering advice on medicine.
It will be heard, that's for sure. The question is whether it's any good. And if you ask people who studied the matter (in this case management theory or flow), well, as fun as ShapeUp or Rework sounds, don't bet too much on those.