Congratulations! I think you make your point well.
Since you requested some feedback: while reading the piece, I did notice that you’re sometimes spending more sentences than necessary, sometimes on discussing what you’re not discussing.
E.g. in the section “Design”, you might consider mostly deleting the first three paragraphs and the image, leaving only “when working with striped development, I often like to think of it as a three-step process: (…) begun to stabilize”.
E.g. in the section “Implementation”, you could simply delete “As this isn’t meant to be a post about how to write code, there isn’t all that much to say about the implementation phase.”
Nonetheless, I do - again - think you make your point well, and I hope you continue to submit relevant posts here. ;-)
I like this. it reads to me like a take on vertical slicing, which I wish was better known amongst engineers. One of these days I should try something like Elephant Carpaccio with my team at work.
Thanks for the kind words, and for the links. I knew there must have been some writing about this previously, so I’ll have to read through that to understand how they compare.
I’ve used this approach with a few different teams in the past to good effect, though never explained in quite so much detail. Sprints or milestones can both be organized around stripes very easily. That’s part of what I like about the strategy - it applies equally as well to team development as it does to individual.
Another term that may come up is a “spike”, which is a vertical slice that is as narrow as possible. You might make a prototype that shows off only one feature, for example.
I feel one really has to be careful with this approach. I read the “Elephant Carpaccio” more thoroughly than the “vertical slicing”, but both seem to be about slicing down work in an Agile environment in tickets. The “Elephant Carpaccio” takes this to an extreme with tickets that take only 15 minutes to implement.
Of course, it all depends on where you’re coming from (how big your job tasks are at the moment) and what experience you have. A more experienced engineer will be happy with a big chunk and wants to do the slicing on their own. A less experienced engineer might need smaller chunks. That’s why I got so hung up on the 15 minutes per ticket, because that’s extreme in my opinion.
In my opinion this approach can - depending on who writes the tickets - easily lead to complete micromanagement of engineers where any real software engineering is completely overlooked. I have a picture in my head where product management defines in extremely small steps “Give us A”, “Give us B”, “Give us C” and at some point the engineer starts to recognize “If they had given me the clear picture in advance, I could have designed the software completely different according to best practices.”
It’s true that this could be abused; but then again, so can many things. If you team isn’t trusted to deliver independently, and the attitude from management is to micro-manage rather than to support independence, then that’s not something you can paper over.
The really fine grained examples are mostly there for training purposes. Like most things, you can start taking bigger steps as you get more confident.
I’m mostly interested because when you have a pull request (say) that forms a complete increment of observable functionality, then it’s a a lot easier to review. Not just in terms of say, will this work, or is this maintanable, but will this work well in context.
For example, at work we’ve a convention that if an object isn’t found when reading it, we’ll return a nil from our data access layer instead of an error. So, I managed to produce a pull request which would crash instead of yielding an error, if I tried to read a non-existent object. Thankfully, my team-mate spotted that one almost immediately. On the other hand, if I’d submitted seperate pull requests for say, the data storage layer, and our request handlers, it would have been harder to spot.
Your first stripe in particular reminds me a bit of tracer bullet development. Your stripes are a bit more fully formed than the tracer bullets I’ve seen, however.
I use this at work and at home and it works great. Generally, when you’re not sure how to do something, just stub it out, or look for ways to solve 20% of the problem now rather than 100% in a month.
I’ve been wanting to write publicly for years, but haven’t gotten around to it until now.
Independent of the content, I would greatly appreciate any feedback on writing style, voice, the included diagrams, etc!
Congratulations! I think you make your point well.
Since you requested some feedback: while reading the piece, I did notice that you’re sometimes spending more sentences than necessary, sometimes on discussing what you’re not discussing.
Nonetheless, I do - again - think you make your point well, and I hope you continue to submit relevant posts here. ;-)
Thank you! This is exactly the type of feedback I’m looking for. Greatly appreciated.
FYI, on smaller screens, the top and bottom halves of the side navigation crash into each other and cause a layout issue.
Interesting, thank you. I checked it on mobile but not a small display. I’ll have to fix this tonight!
Edit: top half of the sidebar has been disabled until I can fix this, thanks again!
I especially like the “Stripes are completed left to right” diagram. It makes it really clear what this is all about.
I like this. it reads to me like a take on vertical slicing, which I wish was better known amongst engineers. One of these days I should try something like Elephant Carpaccio with my team at work.
Thanks for the kind words, and for the links. I knew there must have been some writing about this previously, so I’ll have to read through that to understand how they compare.
I’ve used this approach with a few different teams in the past to good effect, though never explained in quite so much detail. Sprints or milestones can both be organized around stripes very easily. That’s part of what I like about the strategy - it applies equally as well to team development as it does to individual.
Another term that may come up is a “spike”, which is a vertical slice that is as narrow as possible. You might make a prototype that shows off only one feature, for example.
I feel one really has to be careful with this approach. I read the “Elephant Carpaccio” more thoroughly than the “vertical slicing”, but both seem to be about slicing down work in an Agile environment in tickets. The “Elephant Carpaccio” takes this to an extreme with tickets that take only 15 minutes to implement.
Of course, it all depends on where you’re coming from (how big your job tasks are at the moment) and what experience you have. A more experienced engineer will be happy with a big chunk and wants to do the slicing on their own. A less experienced engineer might need smaller chunks. That’s why I got so hung up on the 15 minutes per ticket, because that’s extreme in my opinion.
In my opinion this approach can - depending on who writes the tickets - easily lead to complete micromanagement of engineers where any real software engineering is completely overlooked. I have a picture in my head where product management defines in extremely small steps “Give us A”, “Give us B”, “Give us C” and at some point the engineer starts to recognize “If they had given me the clear picture in advance, I could have designed the software completely different according to best practices.”
It’s true that this could be abused; but then again, so can many things. If you team isn’t trusted to deliver independently, and the attitude from management is to micro-manage rather than to support independence, then that’s not something you can paper over.
The really fine grained examples are mostly there for training purposes. Like most things, you can start taking bigger steps as you get more confident.
I’m mostly interested because when you have a pull request (say) that forms a complete increment of observable functionality, then it’s a a lot easier to review. Not just in terms of say, will this work, or is this maintanable, but will this work well in context.
For example, at work we’ve a convention that if an object isn’t found when reading it, we’ll return a nil from our data access layer instead of an error. So, I managed to produce a pull request which would crash instead of yielding an error, if I tried to read a non-existent object. Thankfully, my team-mate spotted that one almost immediately. On the other hand, if I’d submitted seperate pull requests for say, the data storage layer, and our request handlers, it would have been harder to spot.
Your first stripe in particular reminds me a bit of tracer bullet development. Your stripes are a bit more fully formed than the tracer bullets I’ve seen, however.
I use this at work and at home and it works great. Generally, when you’re not sure how to do something, just stub it out, or look for ways to solve 20% of the problem now rather than 100% in a month.
You may also enjoy Shape Up from the Basecamp folks, which discusses this idea using their notions of “scopes” and “slicing”.