Re: the trouble with auditors
Yes the numbers are based on materiality. They don't examine every single item, they make sure the numbers roughly add up. Ask Ms Hodge about her own company who also don't pay there full whack in tax. Pot kettle.
7 publicly visible posts • joined 4 Dec 2007
Android makes no money, which explains why no one before Oracle is sueing Google. Now even if Oracle win, they will struggle to make a case for massive damages on a product which is making a loss.
http://www.theregister.co.uk/Design/graphics/icons/comment/facepalm_32.png
A clear case of moving goal posts - No project, no matter how well run or how experienced the resource facilitating the project will ever be able to provide a solution where you are changing the process at the same time. Define the process, standardise the process, ensure it works, then start to build a system around it. If it doesnt work as a manual process, its bound to fail as an IT project. At the end of the day the contractors are there to deliver to specification, no more, no less. If your specification is garbage, then you deserve everything you get. Unfortunately this means the taxpayer paying for inept systems and contracts.
So Google gives hardware manufacturers a sneak peak of the software in exchange for building to a particular specification. Well how else are they going to test Android! Kinda helps to have Motorola in the fold to make the reference platform process quicker and simpler. Does this provide any advantage - well if Xoom is anything to go by, no it doesnt.
Epic Fail
Sorry have I misread the article? Android has less bugs than the industry standard (an average of what it doesnt say and quite useless statistic) but it leaks like a sieve. Shame on you register, I expect better from you, god know why. I'm all for bashing the big guns but c'mon!
Just to add my thoughts on the subject, I agree that sometimes it can be advantageous to have multiple exit points. However for commerial grade software, a single exit point is one "best practise" that has simplified my maintainance headaches. If you look in isolation at this practice, it does seem strict, however over the project lifecycle, it does simplify, requirements, design, development, testing and maintainance. If your in the fortunate position where your dont have other people updating your code, I dont believe it matters - apart from a personal style perspective. Working in a team, does require more discipline and this is certainly one that will help you and your team long term. The best analogy for your proposal is the film "Next" where the character can see 2 minutes into the future and uses this ability to check multiple paths. If your team has this ability then cool - go with it, for mere mortals keep it simple sweetie. Remember software engineering is a science and the fundimentals help to deliver robust, maintainable, efficient code.