oooh... That puts the Nexus One equal or beyond the 3gs now?
On Feb 3, 9:08 am, Casper Bang wrote:
> Looks like Google finally decided to flick Apple the finger,
> yay:http://www.engadget.com/2010/02/02/nexus-one-gets-a-software-update-e...
>
> On Feb 2, 4:21 pm, Casper Bang wrote:
>
>
>
> >
Looks like Google finally decided to flick Apple the finger, yay:
http://www.engadget.com/2010/02/02/nexus-one-gets-a-software-update-enables-multitouch/
On Feb 2, 4:21 pm, Casper Bang wrote:
> More evidence of
> dictatorship:http://www.techcrunch.com/2010/02/02/apple-stanza-usb/?utm_source=fee.
I think the emphasis of using usage data to figure out exactly how folks
are using your app is a good measure. It's nice to at least have some
backup when someone says "we need to update blah because of ..." you can
at least say well four people used that feature last year so if you
really want it,
Saying no is not an option usually.
The problem comes when IT is expected to something quick for this task or
project.
Later another project comes along and wants something quick. It can't be
done easily because of the previous project. They are told it will take
longer and they don't understand
On Tue, Feb 2, 2010 at 9:49 PM, Todd Costella wrote:
> Somewhat related to this discussion is the excellent post by Lukas
> Mathis: http://ignorethecode.net/blog/2010/02/02/removing-features/
>
Now I have to stop and call BS :)
I'm all in favor of removing features.
I'm not in favor of saying no
Somewhat related to this discussion is the excellent post by Lukas
Mathis: http://ignorethecode.net/blog/2010/02/02/removing-features/
From: javaposse@googlegroups.com [mailto:javapo...@googlegroups.com] On
Behalf Of Robert Casto
Sent: Tuesday, February 02, 201
On Tue, Feb 2, 2010 at 9:43 PM, Robert Casto wrote:
> Does it fall to us to educate management though? I find that long term
> issues tend to be overlooked since the immediate need is great, here, and
> now. Let tomorrow fend for itself.
>
I've been thinking about writing a presentation on the t
Does it fall to us to educate management though? I find that long term
issues tend to be overlooked since the immediate need is great, here, and
now. Let tomorrow fend for itself.
The problem that IT tends to pay big time from this approach, not those who
make the decisions.
On Tue, Feb 2, 2010 a
On Tue, Feb 2, 2010 at 9:32 PM, Robert Casto wrote:
> Exactly. Customers always want more. There is always something else that
> can be done.
>
> IT just says yes even when it makes no sense. We need to do a better job of
> educating users that there are costs associated with their requests. Not
Exactly. Customers always want more. There is always something else that can
be done.
IT just says yes even when it makes no sense. We need to do a better job of
educating users that there are costs associated with their requests. Not
just to make the change, but to be able to maintain it, documen
Steven Herod wrote:
Oh bullshit (re: the article)
I've seen plenty of cheap stuff thrown together that's perfectly fit
for purpose - once crap reaches steady state, its doesn't matter how
its written, as long as it doesn't need to change. And plenty of
software systems can be written and never
On Tue, Feb 2, 2010 at 9:14 PM, Steven Herod wrote:
> Oh bullshit (re: the article)
>
> I've seen plenty of cheap stuff thrown together that's perfectly fit
> for purpose - once crap reaches steady state, its doesn't matter how
> its written, as long as it doesn't need to change. And plenty of
>
On Tue, Feb 2, 2010 at 21:14, Steven Herod wrote:
> I've seen plenty of cheap stuff thrown together that's perfectly fit
> for purpose - once crap reaches steady state, its doesn't matter how
> its written, as long as it doesn't need to change.
Looking back the last about 10 years what you write
Oh bullshit (re: the article)
I've seen plenty of cheap stuff thrown together that's perfectly fit
for purpose - once crap reaches steady state, its doesn't matter how
its written, as long as it doesn't need to change. And plenty of
software systems can be written and never need to change for the
More evidence of dictatorship:
http://www.techcrunch.com/2010/02/02/apple-stanza-usb/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+Techcrunch+(TechCrunch)
On Feb 1, 11:48 pm, Christian Catchpole
wrote:
> I came from the era of the Amiga. An awesomely design personal
> computer for th
On Tue, Feb 2, 2010 at 09:18, Viktor Klang wrote:
> On the topic of LoC, please read Uncle Bob's latest: http://bit.ly/cYQlvB
Liked that article.
Regarding LOC or number of classes or whatever statistic that covers
code or tracks issue solving:
a) Coding is only a part of the development proces
At the bottom of each page it says that Oracle is reviewing the Sun
product roadmap blah blah blah:
http://uk.sun.com/training/catalog/courses/CX-310-052.xml
So things are in limbo until the big O decides.
Cheers
Paul
On Jan 30, 6:57 pm, Steve Sobczak wrote:
> Is there any word out on the bra
On the topic of LoC, please read Uncle Bob's latest: http://bit.ly/cYQlvB
On Tue, Feb 2, 2010 at 6:43 AM, Reinier Zwitserloot wrote:
> The usual strategy here is to get the dev team together, and decide to
> spend 1 day (or 1 week, whatever the management cycle is), spending it
> only on fixing b
18 matches
Mail list logo
