Yes, and to get people to think about how it could fail for them, you need to paint a picture in their mind of how it failed for you -- so they can emotionally connect. Otherwise you're just writing one-line platitudes: think about how you release, be sure to debug, think about design before coding, etc.
It's all good stuff, no doubt, but without a frame to pull the reader in it loses a lot of impact.
It's a style thing. Do what comes natural to you. I didn't like your post, because to me there was nothing there. I already know that teams that don't think about the big picture and just push to release get caught in a tweak-debug-release cycle. That's just me, though. Personally I would have enjoyed learning if you started off with a design, what happened to it? Who was driving your release cycle? How often was too often for you? Did you have a master release plan that you threw away, or did you never think that far ahead? Etc. It's the details of the thing that matter: everybody already knows the one-liner (or think they do)
That's just me. No worries here. Glad to see you writing and submitting. Look forward to reading more of your work.
It's all good stuff, no doubt, but without a frame to pull the reader in it loses a lot of impact.
It's a style thing. Do what comes natural to you. I didn't like your post, because to me there was nothing there. I already know that teams that don't think about the big picture and just push to release get caught in a tweak-debug-release cycle. That's just me, though. Personally I would have enjoyed learning if you started off with a design, what happened to it? Who was driving your release cycle? How often was too often for you? Did you have a master release plan that you threw away, or did you never think that far ahead? Etc. It's the details of the thing that matter: everybody already knows the one-liner (or think they do)
That's just me. No worries here. Glad to see you writing and submitting. Look forward to reading more of your work.