I'm not saying the developers can't talk to the client, but when it comes to requirements, the business analyst should be there and should be the one that gets the sign off. The developer shouldn't the focal point of contact in these matters because otherwise the client will end up using the developer's time to manage requirements instead of the analyst, this detracts from development time and inevitably will cause schedules to slip. It also causes undue pressure on the developer, because the developer is the one that has to develop the code, inevitably they will get pushed into a corner where they will accept something as a requirement (human nature unfortunately) in order to deliver something on schedule.
Yes, don't let any of the folks doing any work talk to a user for crying out loud!
There is no issue with talking to the user, but anything that involves changing requirements should involve the business analyst, get the requirement written up and signed off. That includes clarifications, otherwise you're putting your project at a higher risk of not delivering what the client wants as well as a creating risks where the client goes back on their word and then claims this wasn't part of the signed off specification.
Do you work for Accenture by any chance?
Never worked for or with Accenture. But I have been on enough projects that involved problems created by misunderstandings and lack of procedure.
Yes, but this should be done prior to code writing.
Considering how often clients will sign off on something and then double back on what they signed off on, and ask for changes and sign off on those new changes which then invalidate some requirements that were previously implemented but because they were signed off, it's a requirement... I think expecting these situations to be completely resolved beforehand is wishful thinking.
Me: "Did you ask if X would ever need to be reconfigured?"
Developer: "Of course! And the client said that sure, if I could make it configurable, go ahead and do so"
Why is the developer handling requirements and not someone dedicated to dealing with business logic? Your developer should be talking to your project's business analyst about these things, not the client. Your projects don't sound very well setup, you're clearly missing vital controls. No wonder why you have problems with developers.
They're back to their pre-firing number of employees; it was mostly an excuse to replace the worst performers. The security system in place seems fairly solid, but I'm not at liberty to discuss how...
Forgive me if I don't see why anyone should listen to an AC without any evidence and implies we should trust them on this.
A common issue I have seen with PC gaming is that the interaction that you will need to do at some point through a mouse and keyboard does not work well in a living room. That is really the only the only genuine issue I have encountered and stuff like Steam's Big Picture pretty much helps resolve that.
Your cell phone doesn't have a 360-like controller.
I have a bluetooth 360-like controller that works with my cell phone.
Your cell phone likely won't play games on your TV.
My xperia z works fine with televisions. I can connect to Bravia screens wirelessly.
Every game on the OUYA can be tried for free. You don't have to put a credit card in to start downloading apps from the store.
I believe I can do that with the Amazon and Playstation Network stores.
Mother-fucking-Towerfall
Never heard of it.
Consider that many people consider $99 media center appliances to be a good bargain. Now consider a device at the same price that includes a gaming controller and plays games.
Or I could just spend less and buy a bluetooth controller for my phone.
Check out all the comments under the story. Literally no one but you is trying to claim that there's no problem because there's the support library. No one.
So it's whose correct based on the quantity of people's responses that support that argument? Okay, sure, you're right. My point of view is completely invalid then.
Posted else where, the argument against it has been:
the majority of users are holding back the advancement of the platform by preventing developers from embracing the latest features and advancements
I have pointed out this is not the case with the support library.
No one else would claim a band-aid means there's no injury.
Then convince me! Surely you can actually name something specific, in practice, that has visible 'injury' to a good chunk of Android developers and users where the support library fails to accommodate.
It really isn't that hard to get me to change my opinion if it's the truth, because the truth will likely have evidence of some sort to back you up. So far my actual experiences with the Android platform (development and user wise) haven't shown me 'injuries' or 'preventing developers from embracing the latest features and advancements'.
Similarly the magic pixie dust that you think the Android Support Library is only supplies partial API support gojng back to API Level 4. Users of level 1 to 3 are out of luck.
As far as I am aware, the lowest OS version ever made public with a handset was version 3 (and it was just one handset), and this was on a device that Google offered updates to, and did so all the way to 'Gingerbread' (reached API level 10). So, I don't know what you mean by out of luck. They can update the OS just fine, unlike the iOS users.
It's a Band Aid over the problem that with Android, MOST users are using a years old version of the OS
It's a problem? The original argument that these users are holding Android back is shown to be invalid because of the support library.
Some hardware APIs would not be available (not missing) if the OS doesn't support related hardware, such as the EDMA API if the OS doesn't recognise a EDMA peripheral. Generally, if you're developing a universal application, you would have reasonable fall backs or just rely on more generic HAL APIs to deal with this. Alternatively, I would say a closer description is that some APIs are significantly different. For example, providing deprecated API calls, or more detailed API functionality to deal with the differences with APIs, such as dealing with Fragments on different OS levels.
This is really a non-issue though, because you're targeting the support library rather than a very specific android/hardware setup.
Oh neat, i can have every app I install bloated to shit with half an OS worth of support libraries. Sounds like a winner idea to me!
Sounds like they haven't used the support library in the normal way (since it will only include the specific APIs you're using, most applications don't even use that many OS APIs).
I don't really understand the problem of targetting software versions when you have the support library, as for hardware, targeting on making your application run decently on the lowest common denominator is generally sufficient. Faster phones are just going to be... Faster.
Slashdot Mirror
I checked this, but it turned out not to be true. The USA uses and makes plenty of non-free software still.
Sounds pretty hard since that information is not provided with the binary or source.
I'm not saying the developers can't talk to the client, but when it comes to requirements, the business analyst should be there and should be the one that gets the sign off. The developer shouldn't the focal point of contact in these matters because otherwise the client will end up using the developer's time to manage requirements instead of the analyst, this detracts from development time and inevitably will cause schedules to slip. It also causes undue pressure on the developer, because the developer is the one that has to develop the code, inevitably they will get pushed into a corner where they will accept something as a requirement (human nature unfortunately) in order to deliver something on schedule.
There is no issue with talking to the user, but anything that involves changing requirements should involve the business analyst, get the requirement written up and signed off. That includes clarifications, otherwise you're putting your project at a higher risk of not delivering what the client wants as well as a creating risks where the client goes back on their word and then claims this wasn't part of the signed off specification.
Never worked for or with Accenture. But I have been on enough projects that involved problems created by misunderstandings and lack of procedure.
Considering how often clients will sign off on something and then double back on what they signed off on, and ask for changes and sign off on those new changes which then invalidate some requirements that were previously implemented but because they were signed off, it's a requirement... I think expecting these situations to be completely resolved beforehand is wishful thinking.
Why is the developer handling requirements and not someone dedicated to dealing with business logic? Your developer should be talking to your project's business analyst about these things, not the client. Your projects don't sound very well setup, you're clearly missing vital controls. No wonder why you have problems with developers.
How do I use PGP with Zimbra server (webmail) and Zimbra Desktop (desktop client)?
Forgive me if I don't see why anyone should listen to an AC without any evidence and implies we should trust them on this.
Not really, it's kind of big and in the way.
A common issue I have seen with PC gaming is that the interaction that you will need to do at some point through a mouse and keyboard does not work well in a living room. That is really the only the only genuine issue I have encountered and stuff like Steam's Big Picture pretty much helps resolve that.
Note: I am not the grandfather poster.
I have a bluetooth 360-like controller that works with my cell phone.
My xperia z works fine with televisions. I can connect to Bravia screens wirelessly.
I believe I can do that with the Amazon and Playstation Network stores.
Never heard of it.
Or I could just spend less and buy a bluetooth controller for my phone.
So it's whose correct based on the quantity of people's responses that support that argument? Okay, sure, you're right. My point of view is completely invalid then.
Posted else where, the argument against it has been:
I have pointed out this is not the case with the support library.
Then convince me! Surely you can actually name something specific, in practice, that has visible 'injury' to a good chunk of Android developers and users where the support library fails to accommodate.
It really isn't that hard to get me to change my opinion if it's the truth, because the truth will likely have evidence of some sort to back you up. So far my actual experiences with the Android platform (development and user wise) haven't shown me 'injuries' or 'preventing developers from embracing the latest features and advancements'.
Correction: By OS version, I meant API level.
As far as I am aware, the lowest OS version ever made public with a handset was version 3 (and it was just one handset), and this was on a device that Google offered updates to, and did so all the way to 'Gingerbread' (reached API level 10). So, I don't know what you mean by out of luck. They can update the OS just fine, unlike the iOS users.
It's a problem? The original argument that these users are holding Android back is shown to be invalid because of the support library.
Some hardware APIs would not be available (not missing) if the OS doesn't support related hardware, such as the EDMA API if the OS doesn't recognise a EDMA peripheral. Generally, if you're developing a universal application, you would have reasonable fall backs or just rely on more generic HAL APIs to deal with this. Alternatively, I would say a closer description is that some APIs are significantly different. For example, providing deprecated API calls, or more detailed API functionality to deal with the differences with APIs, such as dealing with Fragments on different OS levels.
This is really a non-issue though, because you're targeting the support library rather than a very specific android/hardware setup.
Cool story.
Poor drewm1980, his problem doesn't really exist. :(
And which 'missing' APIs specifically is there going to be a problem with for apps?
Of course it isn't, but it resolves the developer issues. Thereby negating problems with users holding the platform's advancement.
Sounds like they haven't used the support library in the normal way (since it will only include the specific APIs you're using, most applications don't even use that many OS APIs).
Most people don't have that option and this resolves that problem from a developer stand point.
Can you describe why the support library solves them poorly?
Can you give an example of which APIs it lacks?
To be honest, targeting different Android versions isn't that hard thanks to the support library.
What about people like me who bought the Xperia Z, why do we do it?
I don't really understand the problem of targetting software versions when you have the support library, as for hardware, targeting on making your application run decently on the lowest common denominator is generally sufficient. Faster phones are just going to be... Faster.
The other advantage with Android is the support library, it lets you use newer APIs on older systems. I don't believe this is available on iOS.
Or you could just use the support library and get all the benefits of newer APIs on older versions.