4 ms·

> A side effect is that work-life balance is amazing once you get this process working. If you know exactly how much work you need to do and when it needs to ge

> A side effect is that work-life balance is amazing once you get this process working. If you know exactly how much work you need to do and when it needs to get done by for the next 4-6 weeks, then you can pace yourself much better. For you this may sound like heaven, but for me (possibly ADHD?) it sounds a little closer to hell. It reminds me of my school days; short assignments were fine. Large multi-week projects were a bit terrifying. So in short, you need to account for a multitude of personality types. People with shorter attention spans need shorter deadlines. People with longer attention spans need less pampering. Pick something that works for both.

CharlieDigital 3y ago
They're not multi-week projects per se; more like: 1. "This is a big feature we are shipping in 6 weeks" 2. "Here are the 20-40 tasks that need to be completed to implement this feature" The only difference is that we've fully planned out 6 weeks of work rather than planning 1 or 2 weeks at a time. I would summarize and say that the difference isn't in the execution; the difference is in the planning. My experience is that it's the opposite for those with short attention spans; because everything is planned out, the engineering team can then kind of walk up to the "buffet table" and pick what they want to work on since you have the full spread. Within that 6 week cycle, we would still build, iterate, and test internally. It's not one giant ticket, but still broken down into parts. At the end of the 6 week cycle, there's a very clear picture of what will be released and there's a formal validation and release period that mostly involves testing and ensuring that the product meets the defined specification.
- MetaWhirledPeas 3y ago
  This sounds a lot like Scrum with longer-than-average sprints. Or maybe its Kanban? I've lost the patience to pay attention to the intricacies of them all. The length of the cycle is going to vary based on your product and your customer. There's a lot to be gained by delivering rapidly if you can do it, with feature flags to hide what you want to keep hidden. 6 weeks for a release is a pretty long time to wait for most projects. Personally, this is my favorite approach, and maybe you'd agree to a point: 1. Team that is focused on the one "big feature" at a time. Maintainers operate on a different team. 2. Big feature should have a planned duration that spans multiple iterations, but not too long. 6 weeks sounds reasonable. 3. Test and deliver as rapidly as you can based on your capabilities. If all your testing is automated, consider Continuous Integration at the very least. If you rely on a team of testers then come up with an iteration length that gives testers enough time to regression test a snapshot of the code to prepare a release candidate, while still allowing enough time in-between for testing new changes. The reason 3 is important is because, whenever possible, you want to avoid the terrifying mountain of risk that comes with releasing code that has not seen the light of day for months on end. Typically the longer you spend preparing a release, the longer you have everyone panicking when the deadline is approaching and this massive release has a massive backlog of bugs.
  - CharlieDigital 3y ago
    The book is very approachable and free in digital form. I strongly recommend anyone that has an interest in this space skim it and decide on your own. Even if you end up disagreeing with or finding faults, it adds perspective and perhaps there are a few ideas that can be applied. On point 3, that really depends on how rigorous the testing process is. One of my favorite essays on the topic of software engineering is "They Write the Right Stuff" [0] which describes how NASA writes their software and why/how they achieve incredibly low defect rates. NOVA has two documentaries: "Pluto and Beyond" and "Chasing Pluto" that puts this into perspective. The New Horizons team was formed in 2000, the satellite launched in 2006, and 15 years after the kickoff reached Pluto. In the documentary, some of the folks had sent off their kids to college by the time New Horizons reached its primary mission objective; truly a life's work. The stakes aren't that high in life sciences and most programs, but in processes that involve GxP, there's generally a risk of injury so it is still higher than say something like Notion or Reddit. True: even with the most rigorous process, there will be outliers in the real world (for example, we would once in a while run into unprocessable PDFs which had embedded entities). But the software I wrote in this span had an incredibly low defect rate. By the time it had reached production, it went through several cycles of informal testing, formal internal testing and validation, and then customer testing and validation. Also true: this doesn't work for all types of software. For consumer software, I'd release that last stage incrementally instead. Incorporation of automation is absolutely critical; in my quest to speed up this process, I ended up spending a lot of time experimenting with E2E test automation[1] to focus our test and documentation efforts. [0] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff [1] https://youtu.be/RGu0ta6MN1k https://youtu.be/RGu0ta6MN1k, https://youtu.be/qYkphCJjD_k https://youtu.be/qYkphCJjD_k, https://youtu.be/i-sMXPV547s https://youtu.be/i-sMXPV547s, https://www.linkedin.com/pulse/v-word-how-technology-decisions-can-streamline-validation-chen https://www.linkedin.com/pulse/v-word-how-technology-decisio...

CharlieDigital 3y ago

They're not multi-week projects per se; more like: 1. "This is a big feature we are shipping in 6 weeks" 2. "Here are the 20-40 tasks that need to be completed to implement this feature" The only difference is that we've fully planned out 6 weeks of work rather than planning 1 or 2 weeks at a time. I would summarize and say that the difference isn't in the execution; the difference is in the planning. My experience is that it's the opposite for those with short attention spans; because everything is planned out, the engineering team can then kind of walk up to the "buffet table" and pick what they want to work on since you have the full spread. Within that 6 week cycle, we would still build, iterate, and test internally. It's not one giant ticket, but still broken down into parts. At the end of the 6 week cycle, there's a very clear picture of what will be released and there's a formal validation and release period that mostly involves testing and ensuring that the product meets the defined specification.

MetaWhirledPeas 3y ago
This sounds a lot like Scrum with longer-than-average sprints. Or maybe its Kanban? I've lost the patience to pay attention to the intricacies of them all. The length of the cycle is going to vary based on your product and your customer. There's a lot to be gained by delivering rapidly if you can do it, with feature flags to hide what you want to keep hidden. 6 weeks for a release is a pretty long time to wait for most projects. Personally, this is my favorite approach, and maybe you'd agree to a point: 1. Team that is focused on the one "big feature" at a time. Maintainers operate on a different team. 2. Big feature should have a planned duration that spans multiple iterations, but not too long. 6 weeks sounds reasonable. 3. Test and deliver as rapidly as you can based on your capabilities. If all your testing is automated, consider Continuous Integration at the very least. If you rely on a team of testers then come up with an iteration length that gives testers enough time to regression test a snapshot of the code to prepare a release candidate, while still allowing enough time in-between for testing new changes. The reason 3 is important is because, whenever possible, you want to avoid the terrifying mountain of risk that comes with releasing code that has not seen the light of day for months on end. Typically the longer you spend preparing a release, the longer you have everyone panicking when the deadline is approaching and this massive release has a massive backlog of bugs.
- CharlieDigital 3y ago
  The book is very approachable and free in digital form. I strongly recommend anyone that has an interest in this space skim it and decide on your own. Even if you end up disagreeing with or finding faults, it adds perspective and perhaps there are a few ideas that can be applied. On point 3, that really depends on how rigorous the testing process is. One of my favorite essays on the topic of software engineering is "They Write the Right Stuff" [0] which describes how NASA writes their software and why/how they achieve incredibly low defect rates. NOVA has two documentaries: "Pluto and Beyond" and "Chasing Pluto" that puts this into perspective. The New Horizons team was formed in 2000, the satellite launched in 2006, and 15 years after the kickoff reached Pluto. In the documentary, some of the folks had sent off their kids to college by the time New Horizons reached its primary mission objective; truly a life's work. The stakes aren't that high in life sciences and most programs, but in processes that involve GxP, there's generally a risk of injury so it is still higher than say something like Notion or Reddit. True: even with the most rigorous process, there will be outliers in the real world (for example, we would once in a while run into unprocessable PDFs which had embedded entities). But the software I wrote in this span had an incredibly low defect rate. By the time it had reached production, it went through several cycles of informal testing, formal internal testing and validation, and then customer testing and validation. Also true: this doesn't work for all types of software. For consumer software, I'd release that last stage incrementally instead. Incorporation of automation is absolutely critical; in my quest to speed up this process, I ended up spending a lot of time experimenting with E2E test automation[1] to focus our test and documentation efforts. [0] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff [1] https://youtu.be/RGu0ta6MN1k https://youtu.be/RGu0ta6MN1k, https://youtu.be/qYkphCJjD_k https://youtu.be/qYkphCJjD_k, https://youtu.be/i-sMXPV547s https://youtu.be/i-sMXPV547s, https://www.linkedin.com/pulse/v-word-how-technology-decisions-can-streamline-validation-chen https://www.linkedin.com/pulse/v-word-how-technology-decisio...