The difference is in the exact motivation involved. In my experience, many managers place a far higher premium on reducing risks than they do on increasing profit. Given the choice between high profit that may suddenly vanish due to some problem, or lower profit and a belief that they've defended against every problem they can think of, the vast majority of managers will choose the lower profit option.
In this context, change of programming languages and tools is seen as a risk, and mandated stability is seen as the defence. In reality, the world is a very dynamic place, it's only fair to ourselves and our employers/clients if we also point out that there's a counterbalancing risk of losing disenchanted developers if stagnation is allowed to set in. On 2 December 2011 10:05, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>wrote: > On Fri, 02 Dec 2011 10:41:25 +0100, Kevin Wright <kev.lee.wri...@gmail.com> > wrote: > > The problem with that kind of money-first approach is that it's falling >> into the trap of disregarding developers, and seeing them as a mere >> interchangeable "resource" for converting time into $$$, and technology >> choice determining the exchange rate. >> >> This is exactly what we've been accusing others of doing, so we really >> want >> to avoid becoming our own worst enemies here! >> > > Well, I don't recall to have accused anyone, and in any case the primary > purpose of a corporate should be precisely "managing resources to convert > time in $$$ and maximizing the exchange rate". Money-first is a must > because without money we can't act, just talk. > > > Perhaps a more influential argument would be: >> >> "This is frustrating our developers, and is damaging our ability to both >> acquire and retain talent. Good programmers don't want to see their >> skills >> stagnating, and there's still a strong market for good engineers even in >> this recession. I'm concerned that some of our most capable people will >> vote with their feet and it's going to hurt our bottom line. There's a >> very real risk that we'll lose people who we can't then replace, and >> here's >> how I think that risk can be mitigated..." >> > > Good and I don't see in contrast with my previous quote-delimited > statement. Just, again: please prove it in business language. Are talented > developers really flying away? Yes. So, let's stress the point to the > management, it shouldn't be hard to point out a fact. Aren't they flying > away? Hmm... Perhaps, we can change things: are you a frustrated talented > developer? Please fly away from that company. You can't? Well, back to the > drawing board. > > > -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > fabrizio.giud...@tidalwave.it > http://tidalwave.it - http://fabriziogiudici.it > -- Kevin Wright mail: kevin.wri...@scalatechnology.com gtalk / msn : kev.lee.wri...@gmail.com quora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda <kev.lee.wri...@gmail.com> twitter: @thecoda vibe / skype: kev.lee.wright steam: kev_lee_wright "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
