[theegoldenone]

So the new OS is out. There are several missing features and a few "bugs".

What would you rather have? 1 big update that addresses many items at once, though it may take longer to release, or small incremental updates that may address one or two items?

I think I prefer the bigger update because it could potentially make more people happy, as there may be a little bit of everything in the release vs an incremental release that some really wanted while others could care less about. The downside of the bigger update is there will be items in the update that have been sitting there ready to go but has to wait for the release.

Thoughts??

Posted via CB10

[eddy_berry]

Great question. I think...

What would you rather have? 1 big update where people complain for a month or two straight that BB is not doing enough. Or, many little increments where people will be happy that issues are being fixed left, right and center, but BB10 devs are constantly putting together another mini update and we are updating the OS on our phone every week.

I think the latter doesn't sound too bad for us but could be exhausting to developers. And having one big update would be exhausting to us CB members. lol.

I would like to see a good mix. Not too often but often enough to fix issues in a timely manner.

[wolf_359]

Small updates more often. While, like you, i can wait, many will not. If they don't see living proof of commitment from BB to improve this phone by way of fairly frequent updates, they will move on. Lots of buzz right now, can't let it cool down.

[joshua_sx1]

I want an update that fix common bugs and enhance performances... regardless it is small or big updates..

[habicht]

Fix issues as fast as you can but add some features with a new release (10.1).

Waiting with bug fixes is nonsense...

Posted via CB10

[chrysaurora]

Both. And both serve a different purpose.

-- Incremental updates every 3 weeks. Fix bugs, enhance existing features, add minor options etc.
This gives them 2 weeks to develop/code. 1 week to test and push out update.

-- Major updates every 9 weeks. Introduce new features, major updates to apps and/or underlying code, major enhancements.
This gives them 6 weeks to develop/code, 2 weeks to test and push out update.

[theegoldenone]

Both. And both serve a different purpose.

-- Incremental updates every 3 weeks. Fix bugs, enhance existing features, add minor options etc.
This gives them 2 weeks to develop/code. 1 week to test and push out update.

-- Major updates every 9 weeks. Introduce new features, major updates to apps and/or underlying code, major enhancements.
This gives them 6 weeks to develop/code, 2 weeks to test and push out update.

I'm a programmer, and specific time frames like that are unrealistic. But I understand the jest of what saying.

Posted via CB10

[chrysaurora]

I'm a programmer, and specific time frames like that are unrealistic. But I understand the jest of what saying.

Posted via CB10

I am too. Scrum. 1 to 2 week sprints are very much possible.

[acadia1106]

I'm a programmer, and specific time frames like that are unrealistic. But I understand the jest of what saying.

Posted via CB10

If you are developer then you should be familiar with the agile method of development, which is exactly that 4 to 6 week chunks, with less focus on creating vast requirements, and huge documents bu t rather getting work done.

I think agile today is far more relevant than the waterfall approach you are suggesting. Bberry could definitely go with this approach, and I personally like it better as more people will get there concerns addressed at a faster pace, more importantly you don't get the unruly releases, with so many things to test


Posted via CB10

[metz9444]

Well I DID stay at a Holiday Inn Express and since that now makes me an expert too, quit comparing proverbial Johnsons and just except that both of you are right. The OS is set up to make updates in the background a reality but that has to be balanced with the potential problem of annoying people with contstant updates.

Posted via CB10

[jagoct23]

I think that big updates are better because of the carrier involvement. Updates need to be big enough that carriers can't not push them. If you start doing small updates the carriers will be more likely to drag their feet rolling them out, and then you have too much disparity. I'm looking at you Verizon.

Posted via CB10

[jrlong]

Ha, as I'm reading down I'm thinking, "This is going to turn into a discussion about Agile development." Sure enough...

For those that think drink the Agile Koolaid, I dare say you may be missing the point : it's a development process, not a release process. Agile adds a healthy mix of thinking into a development environment, but I think there are still elements of the good old waterfall model that will always apply. At some point, one must do integration and regression testing prior to releasing a build. I can't see how a release schedule shorter than 6 weeks is possible. For an OS, 3 months seems aggressive.

I also think there's a danger of angering consumers with too many updates. The installed base starts to fragment, and no one knows what's going on. Too many updates also suggests a crappy product, especially if updates start coming to fix new bugs from a previous update that wasn't tested properly (cough, Firefox, cough) .

What I'd love to have is a choice. I would happily beta test release candidates where you could subscribe to more frequent updates. This would also give us a little more feeling of Android that I find missing due to the non hack-ability of BlackBerry. That'll probably never happen...

Posted via CB10

[chrysaurora]

Ha, as I'm reading down I'm thinking, "This is going to turn into a discussion about Agile development." Sure enough...

For those that think drink the Agile Koolaid, I dare say you may be missing the point : it's a development process, not a release process. Agile adds a healthy mix of thinking into a development environment, but I think there are still elements of the good old waterfall model that will always apply. At some point, one must do integration and regression testing prior to releasing a build. I can't see how a release schedule shorter than 6 weeks is possible. For an OS, 3 months seems aggressive.

I also think there's a danger of angering consumers with too many updates. The installed base starts to fragment, and no one knows what's going on. Too many updates also suggests a crappy product, especially if updates start coming to fix new bugs from a previous update that wasn't tested properly (cough, Firefox, cough) .

What I'd love to have is a choice. I would happily beta test release candidates where you could subscribe to more frequent updates. This would also give us a little more feeling of Android that I find missing due to the non hack-ability of BlackBerry. That'll probably never happen...

Posted via CB10

+1.
That said, it's entirely possible to have
1. Incremental updates every 3 weeks or so (2 weeks development & unit testing, 1 week of integration, regression testing etc.). These would be bug-fixes kind of updates. Or minor functionality enhancement. Something that can be developed and tested in <3 weeks. And also something that does NOT require carrier re-testing.

2.Major updates every 9 weeks (6 weeks development & unit testing, 3 weeks of integration, regression testing etc.). These will contain some substantial enhancement, introduction of new features. And even changes that might require some carrier testing (eg: enhancement to radio stack or kernel level changes might necessaite carrier testing s)

As far as agile goes: well, it depends on how you look at it. In this specific context, what is an 'update' project? It is inherently lends itself to agile model (or at-least, series of mini waterfall).

Once a product has been released, you are simply enhancing features and/or fixing bugs (based on end-user feedback and test results). So, say you've gathered a list of 20 code-changes (bug fixes, enhancements etc.). Now, you prioritize this list in order of importance. And then you sort them into what are easy fixes (low hanging fruits) and what require major coding effort.

Then you code them. Easy fixes get released in 3 weeks incremental updates. Major coding-efforts get released in next incremental release or with the 9-weekly major update.

In the meantime - you CONTINUE to get end-user feedback (bug reports, feature requests) so you keep adding that to your existing list of stuff that needs to be done. And keep sorting that list, re-prioritizing and re-ordering that list of tasks.

So, I guess, updates are inherently agile.

EDIT:
Just wanted to add this: let's also not underestimate the psychological (feel good) effect that a regular (neither too infrequent nor too frequent) update cycle has on end-user's mood. I personally feel like our voice is being heard and bugs are being fixed. That the company stands behind its product and is pro-active about my (the customer's) satisfaction. It makes me feel good about buying from this particular company. Not sure what to call it - but such happy feelings inspire brand loyalty? good will?

[DatMisterB]

I agree with chrysaurora. You should have scheduled minor AND major updates.

[BB Marissa]

The problem with mini updates is that carriers will not go to the effort of approving them. It's already been seen with some of the carriers releasing the Z10, that they are waiting for the cumulative update.
If BlackBerry were releasing the updates themselves, it wouldn't be an issue.

Posted via CB10

[chrysaurora]

The problem with mini updates is that carriers will not go to the effort of approving them. It's already been seen with some of the carriers releasing the Z10, that they are waiting for the cumulative update.
If BlackBerry were releasing the updates themselves, it wouldn't be an issue.

Posted via CB10

Agree. To circumvent that problem, I said,

1. Incremental updates every 3 weeks or so (2 weeks development & unit testing, 1 week of integration, regression testing etc.). These would be bug-fixes kind of updates. Or minor functionality enhancement. Something that can be developed and tested in <3 weeks. And also something that does NOT require carrier re-testing.

Carrier doesn't test ALL updates. Only updates that touch a particular functionality (usually changes in radio stack). Those updates can be saved for scheduled major updates.

[acadia1106]

Ha, as I'm reading down I'm thinking, "This is going to turn into a discussion about Agile development." Sure enough...

For those that think drink the Agile Koolaid, I dare say you may be missing the point : it's a development process, not a release process. Agile adds a healthy mix of thinking into a development environment, but I think there are still elements of the good old waterfall model that will always apply. At some point, one must do integration and regression testing prior to releasing a build. I can't see how a release schedule shorter than 6 weeks is possible. For an OS, 3 months seems aggressive.

I also think there's a danger of angering consumers with too many updates. The installed base starts to fragment, and no one knows what's going on. Too many updates also suggests a crappy product, especially if updates start coming to fix new bugs from a previous update that wasn't tested properly (cough, Firefox, cough) .

What I'd love to have is a choice. I would happily beta test release candidates where you could subscribe to more frequent updates. This would also give us a little more feeling of Android that I find missing due to the non hack-ability of BlackBerry. That'll probably never happen...

Posted via CB10

It's no more complicated than the number of requirements you are trying to meet, also this isn't cool aid, the size of each sprint is defined by number of requirements its not some hard fast rule it be 6 weeks. The bottom line is the waterfall approach IMHO is outdated and leads to large, time consuming, unruly releases, think about how long regression testing takes as you add more requirements.

A hybrid approach might be optimal, in either case, you need to think politically as well,quick updates is good PR for bberry, bberry is not in the position to have long dev cycles. they need to address concerns of users as soon as possible, and a more agile approach allows this.


Posted via CB10

[theegoldenone]

Regularly SCHEDULED updates will be a recipe for rushed not so finished releases. Only release an update when it is truly and throughly tested. Many "easy" fixes can become coding nightmares. And when "it's got to be done by xx weeks" looms over ones head, professional coding is thrown out the door.

Posted via CB10

[acadia1106]

Regularly SCHEDULED updates will be a recipe for rushed not so finished releases. Only release an update when it is truly and throughly tested. Many "easy" fixes can become coding nightmares. And when "it's got to be done by xx weeks" looms over ones head, professional coding is thrown out the door.

Posted via CB10

Agile approach isn't about a release schedule, it's a reduction in number of features/fixes in a release cycle to reduce the time to release, and create greater collaboration between business and IT groups to meet businesses needs. It's not that somebody goes you have 2 weeks to finish this, now get it done, you still are using aspects of waterfall, you still do requirements, estimates, dev, rest, release, it's just you modularize and put less features at a time , allowing you to more rapidly implwment and release.

Posted via CB10

[ricocan]

I Agree with the concern that scheduled updates can impact quality, but only if each development or fix is tied to the schedule. The only thing that should be set in stone is the schedule, not the particular bug fixes, each fix is done on what ever schedule and time line that is needed, once it is done then it gets added to the next scheduled release, which release cycle it should be On, either the short, long or carrier, would have been figured out at the time it was assigned to a team for fixing.

The bug fixes should not be tied to a particular release date, just the cycle, ensuring quality and a steady stream of releases.

Posted via CB10

[chrysaurora]

I Agree with the concern that scheduled updates can impact quality, but only if each development or fix is tied to the schedule. The only thing that should be set in stone is the schedule, not the particular bug fixes, each fix is done on what ever schedule and time line that is needed, once it is done then it gets added to the next scheduled release, which release cycle it should be On, either the short, long or carrier, would have been figured out at the time it was assigned to a team for fixing.

The bug fixes should not be tied to a particular release date, just the cycle, ensuring quality and a steady stream of releases.

Posted via CB10

Exactly. Some folks here are misunderstanding the approach. Scheduled update doesn't mean that you release imporperly tested code.

Scheduled updates mean - you release fully tested (production quality) updates on a fixed schedule. If some feature is not ready by scheduled-update date, it is moved to next scheduled date.

So, you get frequent updates but the number of features addressed in that update might be smaller. It doesn't mean you get frequent updates but updates are of poor quality. No, updates are of top notch quality.

As I stated earlier, my favored approach (and suggestion to BlackBerry) is something along these lines:

-- Incremental updates every 3 weeks. Fix bugs, enhance existing features, add minor options etc.
This gives them 2 weeks to develop/code. 1 week to test and push out update.

-- Major updates every 9 weeks. Introduce new features, major updates to apps and/or underlying code, major enhancements.
This gives them 6 weeks to develop/code, 2 weeks to test and push out update.