February 10, 2015 at 9:08 pm
Comments posted to this topic are about the item Ship Safe...Ship Often
February 11, 2015 at 2:09 am
...and Bristol fashion???
If everyone is onboard with regards to the two principles then the tension should be considered as a natural safety restrictor i.e. what we want to do tempered by what we have to do. I find that sometimes this tension can be found internal to myself.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 11, 2015 at 6:28 am
I agree. But it seems I am always fighting the 'Get it out the door' mentality. When possible problems are identified, the process is to see if we can live with the fallout and get it fixed as soon as possible as long as we don't upset the higher ups by delaying a roll out.
February 11, 2015 at 7:22 am
Love the article today. As a developer for a manufacturer, these words ring true not only for software development, but for production processes and business processes everywhere. In today's world, if you aren't changing, you are dying. Your article is a great reminder that if we learn to engineer a great change process, we can produce more (aka ship more) with more accurate products (software or widgets) and fewer defects (bugs or warranty issues). You have put to words the ideas I try to evangelize on a daily basis.
Well done, sir!
February 11, 2015 at 7:31 am
Absolutely! Personally I don't buy in to the "fast" mantra. I understand profit motive, but long term, fast is too risky. Like you I believe correct, or safe, is where we need to focus.
I let people know that I will provide the service they want correctly, but I will not sacrifice quality to provide it quickly. 99% of the time I exceed their desires for timeliness, so my customers (end users) are happy to let me get it right. I refuse to provide something that I believe isn't correct.
Dave
February 11, 2015 at 8:07 am
If by deploying often we mean more iterative and incremental deployments, then that can also result in safer deployments, because changes within each release are fewer and more manageable. It's also easier to rollback these small incrmental deployments. What I hate is when a release sits in QA for so long there are additional bug fixes made to production in interim, all of which have to be merged into the next release.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 11, 2015 at 11:30 am
There should be some threshold reached to warrant a new release. One tweak of the UI or a new color in one text box is not enough. In addition, just because it has been a few months without a release, some small fix should not be the only item to release.
Release when it is time, when all is tested, and within reason for the user of the product. Moreover, if there is no significant thing to release, do not do it just because of time passed.
Not all gray hairs are Dinosaurs!
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply