Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ModPerl

highscalability.com report

 

 

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded


jschueler at eloquency

Apr 3, 2012, 7:50 PM

Post #1 of 25 (3092 views)
Permalink
highscalability.com report

Hope this doesn't get trapped by too many spam filters.

Sad news. Just saw a blog

http://www.highscalability.com/

that reports YouPorn.com switched from Perl to PHP. Apparently there's a
reported 10% improvement in speed, but I haven't noticed :).

After a couple months of total immersion, I have less inclination towards
PHP than ever. Fight's not out of me yet.

-Jim


wrowe at rowe-clan

Apr 4, 2012, 12:31 AM

Post #2 of 25 (3023 views)
Permalink
Re: highscalability.com report [In reply to]

On 4/3/2012 9:50 PM, Jim Schueler wrote:
> Hope this doesn't get trapped by too many spam filters.
>
> Sad news. Just saw a blog
>
> http://www.highscalability.com/
>
> that reports YouPorn.com switched from Perl to PHP. Apparently there's a reported 10%
> improvement in speed, but I haven't noticed :).
>
> After a couple months of total immersion, I have less inclination towards
> PHP than ever. Fight's not out of me yet.

If one is comparing an every-connection mod_perl enabled environment
to a specific-content, fastcgi-proxied php buildout, there's no contest.

When was the last time you built perl with no threading support? It's
certainly a 5%-15% win.


margol at beamartyr

Apr 4, 2012, 1:03 AM

Post #3 of 25 (3025 views)
Permalink
Re: highscalability.com report [In reply to]

On 04/04/2012 10:31, William A. Rowe Jr. wrote:
> On 4/3/2012 9:50 PM, Jim Schueler wrote:
>> Hope this doesn't get trapped by too many spam filters.
>>
>> Sad news. Just saw a blog
>>
>> http://www.highscalability.com/
>>
>> that reports YouPorn.com switched from Perl to PHP. Apparently there's a reported 10%
>> improvement in speed, but I haven't noticed :).
>>
>> After a couple months of total immersion, I have less inclination towards
>> PHP than ever. Fight's not out of me yet.
> If one is comparing an every-connection mod_perl enabled environment
> to a specific-content, fastcgi-proxied php buildout, there's no contest.
>
> When was the last time you built perl with no threading support? It's
> certainly a 5%-15% win.
Agreed. Honestly, I love mod_perl for easy Apache internals and for
doing really cool things with the httpd API but if I was given a blank
R&D department and told to build a web site (a public-facing HTML-based
beast, not a webservice or some other API endpoint), I'd very likely
pick PHP. It's faster and simpler (not easier, but simpler) for people
to work with and if set up properly can be fast enough to serve. Since
PHP's APC stabilized, I've always considered it to be "good enough"
against the speed advantage of registry scripts....

Issac


perrin at elem

Apr 4, 2012, 5:31 AM

Post #4 of 25 (3030 views)
Permalink
Re: highscalability.com report [In reply to]

On Tue, Apr 3, 2012 at 10:50 PM, Jim Schueler <jschueler [at] eloquency> wrote:
> that reports YouPorn.com switched from Perl to PHP.  Apparently there's a
> reported 10% improvement in speed, but I haven't noticed :).

We lost YouPorn?! Tragic!

I'd say the joke's on them though. If you rewrite an old site and
only get a 10% speed improvement, that's pretty weak. If they were to
rewrite it in Perl today, it would go up again!

- Perrin


rolf.b.mr at gmail

Apr 4, 2012, 6:13 AM

Post #5 of 25 (3022 views)
Permalink
Re: highscalability.com report [In reply to]

On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins <perrin [at] elem> wrote:

> ...

If they were to
> rewrite it in Perl today, *it would go up again*!
>
> - Perrin
>

No performance anxiety there then.


mike at acorg

Apr 4, 2012, 6:16 AM

Post #6 of 25 (3040 views)
Permalink
Re: highscalability.com report [In reply to]

LOL
----- Original Message -----
From: Rolf Banting
To: Perrin Harkins
Cc: Jim Schueler ; modperl [at] perl
Sent: Wednesday, April 04, 2012 9:13 AM
Subject: Re: highscalability.com report




On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins <perrin [at] elem> wrote:

...
If they were to
rewrite it in Perl today, it would go up again!

- Perrin


No performance anxiety there then.


demerphq at gmail

Apr 4, 2012, 6:37 AM

Post #7 of 25 (3031 views)
Permalink
Re: highscalability.com report [In reply to]

On 4 April 2012 09:31, William A. Rowe Jr. <wrowe [at] rowe-clan> wrote:
> On 4/3/2012 9:50 PM, Jim Schueler wrote:
>> Hope this doesn't get trapped by too many spam filters.
>>
>> Sad news.  Just saw a blog
>>
>>   http://www.highscalability.com/
>>
>> that reports YouPorn.com switched from Perl to PHP.  Apparently there's a reported 10%
>> improvement in speed, but I haven't noticed :).
>>
>> After a couple months of total immersion, I have less inclination towards
>> PHP than ever.  Fight's not out of me yet.
>
> If one is comparing an every-connection mod_perl enabled environment
> to a specific-content, fastcgi-proxied php buildout, there's no contest.
>
> When was the last time you built perl with no threading support?  It's
> certainly a 5%-15% win.

Not certainly. We did that and saw almost no difference.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"


aw at ice-sa

Apr 4, 2012, 7:21 AM

Post #8 of 25 (3025 views)
Permalink
Re: highscalability.com report [In reply to]

Rolf Banting wrote:
> On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins <perrin [at] elem> wrote:
>
>> ...
>
> If they were to
>> rewrite it in Perl today, *it would go up again*!
>>
>> - Perrin
>>
>
> No performance anxiety there then.
>
Particularly with a non-threaded Perl, which allows Apache to fork multiple times..


discobeta at gmail

Apr 4, 2012, 7:23 AM

Post #9 of 25 (3030 views)
Permalink
Re: highscalability.com report [In reply to]

agree, any rewrite of old code should improve by at least 10%, even if it
was written in pascal

On Wed, Apr 4, 2012 at 10:21 AM, André Warnier <aw [at] ice-sa> wrote:

> Rolf Banting wrote:
>
>> On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins <perrin [at] elem> wrote:
>>
>> ...
>>>
>>
>> If they were to
>>
>>> rewrite it in Perl today, *it would go up again*!
>>>
>>> - Perrin
>>>
>>>
>> No performance anxiety there then.
>>
>> Particularly with a non-threaded Perl, which allows Apache to fork
> multiple times..
>
>


dave.morgan at coolplaces

Apr 4, 2012, 7:36 AM

Post #10 of 25 (3027 views)
Permalink
Re: highscalability.com report [In reply to]

Hi All,
So they did a complete rewrite without changing the hardware?
My guess is that the site on the same hardware would be substantially slower.

IMHO
Dave


On 04/04/12 08:23 AM, discobeta wrote:
> agree, any rewrite of old code should improve by at least 10%, even if it was written in pascal
>
> On Wed, Apr 4, 2012 at 10:21 AM, André Warnier <aw [at] ice-sa <mailto:aw [at] ice-sa>> wrote:
>
> Rolf Banting wrote:
>
> On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins <perrin [at] elem <mailto:perrin [at] elem>> wrote:
>
> ...
>
>
> If they were to
>
> rewrite it in Perl today, *it would go up again*!
>
> - Perrin
>
>
> No performance anxiety there then.
>
> Particularly with a non-threaded Perl, which allows Apache to fork multiple times..
>
>


--
Dave Morgan
Operations Manager, Cool Places In Canada
http://www.coolplaces.ca
dave.morgan [at] coolplaces
403 288 8759 / 866 938 0516


milu71 at gmx

Apr 4, 2012, 11:27 AM

Post #11 of 25 (3026 views)
Permalink
Re: highscalability.com report [In reply to]

demerphq schrieb am 04.04.2012 um 15:37 (+0200):

> > When was the last time you built perl with no threading support?
> >  It's certainly a 5%-15% win.
>
> Not certainly. We did that and saw almost no difference.

<digressing>
As I see threads mentioned here: I know that there's some Perl threads
knowledge on this list, so I'd like to draw your attention to a question
I asked on StackOverflow about threads in Perl (as I feel guiding docs
for that topic are lacking).

Use cases for ithreads (interpreter threads) in
Perl and rationale for using or not using them?
http://stackoverflow.com/q/9973860/269126

Maybe you'd like to add some of your knowledge over there. Thanks.
</digressing>

Michael


fred at redhotpenguin

Apr 4, 2012, 11:41 AM

Post #12 of 25 (3026 views)
Permalink
Re: highscalability.com report [In reply to]

On Wed, Apr 4, 2012 at 6:37 AM, demerphq <demerphq [at] gmail> wrote:
> On 4 April 2012 09:31, William A. Rowe Jr. <wrowe [at] rowe-clan> wrote:
>>
>> When was the last time you built perl with no threading support?  It's
>> certainly a 5%-15% win.
>
> Not certainly. We did that and saw almost no difference.

I've done two perlbench sets of comparisons with threaded/non-threaded
across a couple different versions of perl. I don't have the results
posted on the web anymore, but non-threaded was up to 20% faster for
some operations.

As far as real world differences go, I don't think you are likely to
see differences with mod_perl in production environments with threaded
vs non-threaded. That 20% increase probably only affects 1% of your
application.


davehodg at gmail

Apr 4, 2012, 12:26 PM

Post #13 of 25 (3020 views)
Permalink
Re: highscalability.com report [In reply to]

On 4 Apr 2012, at 19:41, Fred Moyer wrote:

> On Wed, Apr 4, 2012 at 6:37 AM, demerphq <demerphq [at] gmail> wrote:
>> On 4 April 2012 09:31, William A. Rowe Jr. <wrowe [at] rowe-clan> wrote:
>>>
>>> When was the last time you built perl with no threading support? It's
>>> certainly a 5%-15% win.
>>
>> Not certainly. We did that and saw almost no difference.
>
> I've done two perlbench sets of comparisons with threaded/non-threaded
> across a couple different versions of perl. I don't have the results
> posted on the web anymore, but non-threaded was up to 20% faster for
> some operations.
>
> As far as real world differences go, I don't think you are likely to
> see differences with mod_perl in production environments with threaded
> vs non-threaded. That 20% increase probably only affects 1% of your
> application.


I would say the app layer performance is the least of your worries. Front-end
caching, CDNs and caching in the intermediate layers will win you much, much
more than fretting about +/- 20% in the speed of the code. And if you have
a scalable architecture, and I'm assuming youporn is, you can always go
sideways very easily.


wrowe at rowe-clan

Apr 4, 2012, 1:55 PM

Post #14 of 25 (3028 views)
Permalink
Re: highscalability.com report [In reply to]

On 4/4/2012 1:41 PM, Fred Moyer wrote:
> On Wed, Apr 4, 2012 at 6:37 AM, demerphq <demerphq [at] gmail> wrote:
>> On 4 April 2012 09:31, William A. Rowe Jr. <wrowe [at] rowe-clan> wrote:
>>>
>>> When was the last time you built perl with no threading support? It's
>>> certainly a 5%-15% win.
>>
>> Not certainly. We did that and saw almost no difference.
>
> I've done two perlbench sets of comparisons with threaded/non-threaded
> across a couple different versions of perl. I don't have the results
> posted on the web anymore, but non-threaded was up to 20% faster for
> some operations.
>
> As far as real world differences go, I don't think you are likely to
> see differences with mod_perl in production environments with threaded
> vs non-threaded. That 20% increase probably only affects 1% of your
> application.

Right. The missing detail/point was that a well-tuned pool of single
threaded PHP, or Perl, or assembly coded worker processes running under
fcgid is going to outperform the in-process model, given finite cpu and
memory resources.


randolf at modperl

Apr 4, 2012, 5:15 PM

Post #15 of 25 (3028 views)
Permalink
Re: highscalability.com report [In reply to]

> Hi All,
> So they did a complete rewrite without changing the hardware?
> My guess is that the site on the same hardware would be substantially slower.

A change to the database design, as well as database engine (e.g.,
to something fantastic like PostgreSQL), indexing strategies, etc.,
would also be expected to have a major impact too.

[End of reply.]

> IMHO
> Dave
>
>
> On 04/04/12 08:23 AM, discobeta wrote:
> > agree, any rewrite of old code should improve by at least 10%, even if it was written in pascal
> >
> > On Wed, Apr 4, 2012 at 10:21 AM, André Warnier <aw [at] ice-sa <mailto:aw [at] ice-sa>> wrote:
> >
> > Rolf Banting wrote:
> >
> > On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins <perrin [at] elem <mailto:perrin [at] elem>> wrote:
> >
> > ...
> >
> >
> > If they were to
> >
> > rewrite it in Perl today, *it would go up again*!
> >
> > - Perrin
> >
> >
> > No performance anxiety there then.
> >
> > Particularly with a non-threaded Perl, which allows Apache to fork multiple times..
> >
> >
>
>
> --
> Dave Morgan
> Operations Manager, Cool Places In Canada
> http://www.coolplaces.ca
> dave.morgan [at] coolplaces
> 403 288 8759 / 866 938 0516


Randolf Richardson - randolf [at] inter-corporate
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/


davehodg at gmail

Apr 5, 2012, 2:58 AM

Post #16 of 25 (3018 views)
Permalink
Re: highscalability.com report [In reply to]

Talking of youporn:

http://gizmodo.com/5899327/how-much-porn-does-the-internet-hold

10 Dual layer DVDs per second.


clint at traveljury

Apr 12, 2012, 7:00 AM

Post #17 of 25 (2956 views)
Permalink
Re: highscalability.com report [In reply to]

On Tue, 2012-04-03 at 22:50 -0400, Jim Schueler wrote:
> Hope this doesn't get trapped by too many spam filters.
>
> Sad news. Just saw a blog
>
> http://www.highscalability.com/
>
> that reports YouPorn.com switched from Perl to PHP. Apparently there's a
> reported 10% improvement in speed, but I haven't noticed :).

I think the bigger factor in the speed improvement is probably to do
with switching from MySQL to Redis

https://groups.google.com/group/redis-db/browse_thread/thread/77841c595d29f983?pli=1

clint


mpeters at plusthree

Apr 12, 2012, 7:05 AM

Post #18 of 25 (2968 views)
Permalink
Re: highscalability.com report [In reply to]

On 04/12/2012 10:00 AM, Clinton Gormley wrote:

> I think the bigger factor in the speed improvement is probably to do
> with switching from MySQL to Redis
>
> https://groups.google.com/group/redis-db/browse_thread/thread/77841c595d29f983?pli=1

They didn't really "switch" from mysql to redis. They are using Redis as
a structured caching layer in front of mysql. Their authoritative data
is still stored in mysql, but they have several "views" of that data
that they export regularly to redis. The site pulls these cached views
from redis and yes that's very fast.

It's kind of similar to a lot of other really big systems (like
facebook). Authoritative data in an SQL database and then their read
data in denormalized structures in a NoSQL database.

--
Michael Peters
Plus Three, LP


orasnita at gmail

Apr 12, 2012, 10:01 AM

Post #19 of 25 (2973 views)
Permalink
Re: highscalability.com report [In reply to]

From: "Clinton Gormley" <clint [at] traveljury>
Subject: Re: highscalability.com report


> On Tue, 2012-04-03 at 22:50 -0400, Jim Schueler wrote:
>> Hope this doesn't get trapped by too many spam filters.
>>
>> Sad news. Just saw a blog
>>
>> http://www.highscalability.com/
>>
>> that reports YouPorn.com switched from Perl to PHP. Apparently there's a
>> reported 10% improvement in speed, but I haven't noticed :).
>
> I think the bigger factor in the speed improvement is probably to do
> with switching from MySQL to Redis
>


Yeah, so there should be other reasons for passing from Perl to PHP.

What could be?

Octavian


eric.berg at barclays

Apr 12, 2012, 10:14 AM

Post #20 of 25 (2933 views)
Permalink
RE: highscalability.com report [In reply to]

Well, finding (good) developers is certainly an issue.

Here in NYC, it's very difficult to find proper Perl programmers as opposed to dabblers and scripters.

One of the larger web sites here in the city was built by a great Perl guy, but as they've grown and become successful, finding Perl talent has become a big issue. I'm told that they're somewhere down the road to moving to PHP.

> -----Original Message-----
> From: Octavian Rasnita [mailto:orasnita [at] gmail]
> Sent: Thursday, April 12, 2012 1:02 PM
> To: Clinton Gormley; Jim Schueler
> Cc: modperl [at] perl
> Subject: Re: highscalability.com report
>
> From: "Clinton Gormley" <clint [at] traveljury>
> Subject: Re: highscalability.com report
>
>
> > On Tue, 2012-04-03 at 22:50 -0400, Jim Schueler wrote:
> >> Hope this doesn't get trapped by too many spam filters.
> >>
> >> Sad news. Just saw a blog
> >>
> >> http://www.highscalability.com/
> >>
> >> that reports YouPorn.com switched from Perl to PHP. Apparently
> there's a
> >> reported 10% improvement in speed, but I haven't noticed :).
> >
> > I think the bigger factor in the speed improvement is probably to do
> > with switching from MySQL to Redis
> >
>
>
> Yeah, so there should be other reasons for passing from Perl to PHP.
>
> What could be?
>
> Octavian


_______________________________________________
Barclays is one of the world's leading banks, and we believe that by continuing to integrate the organisation we can better deliver the full power of Barclays to customers, clients and the communities in which we work.
As a visible sign of that integration we are moving to a single Barclays brand for the majority of our divisions, including those formerly known as Barclays Capital, Barclays Wealth and Barclays Corporate.

_______________________________________________

This e-mail may contain information that is confidential, privileged or otherwise protected from
disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute
it by any means. Please delete it and any attachments and notify the sender that you have received
it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a
solicitation to buy or sell any securities, investment products or other financial product or
service, an official confirmation of any transaction, or an official statement of Barclays. Any
views or opinions presented are solely those of the author and do not necessarily represent those
of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer.
By messaging with Barclays you consent to the foregoing. Barclays offers premier investment banking
products and services to its clients through Barclays Bank PLC, a company registered in England
(number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may
relate to or be sent from other members of the Barclays Group.

_______________________________________________


jschueler at eloquency

Apr 12, 2012, 10:23 AM

Post #21 of 25 (2964 views)
Permalink
RE: highscalability.com report [In reply to]

Chicken and egg problem. I have posted quite a bit about the pain of
migrating my skill set to PHP. And doing whatever I can do stop that
descent. That's what makes the news so "sad", as I posted originally.

-Jim

On Thu, 12 Apr 2012, eric.berg [at] barclays wrote:

> Well, finding (good) developers is certainly an issue.
>
> Here in NYC, it's very difficult to find proper Perl programmers as opposed to dabblers and scripters.
>
> One of the larger web sites here in the city was built by a great Perl guy, but as they've grown and become successful, finding Perl talent has become a big issue. I'm told that they're somewhere down the road to moving to PHP.
>
>> -----Original Message-----
>> From: Octavian Rasnita [mailto:orasnita [at] gmail]
>> Sent: Thursday, April 12, 2012 1:02 PM
>> To: Clinton Gormley; Jim Schueler
>> Cc: modperl [at] perl
>> Subject: Re: highscalability.com report
>>
>> From: "Clinton Gormley" <clint [at] traveljury>
>> Subject: Re: highscalability.com report
>>
>>
>>> On Tue, 2012-04-03 at 22:50 -0400, Jim Schueler wrote:
>>>> Hope this doesn't get trapped by too many spam filters.
>>>>
>>>> Sad news. Just saw a blog
>>>>
>>>> http://www.highscalability.com/
>>>>
>>>> that reports YouPorn.com switched from Perl to PHP. Apparently
>> there's a
>>>> reported 10% improvement in speed, but I haven't noticed :).
>>>
>>> I think the bigger factor in the speed improvement is probably to do
>>> with switching from MySQL to Redis
>>>
>>
>>
>> Yeah, so there should be other reasons for passing from Perl to PHP.
>>
>> What could be?
>>
>> Octavian
>
>
> _______________________________________________
> Barclays is one of the world's leading banks, and we believe that by continuing to integrate the organisation we can better deliver the full power of Barclays to customers, clients and the communities in which we work.
> As a visible sign of that integration we are moving to a single Barclays brand for the majority of our divisions, including those formerly known as Barclays Capital, Barclays Wealth and Barclays Corporate.
>
> _______________________________________________
>
> This e-mail may contain information that is confidential, privileged or otherwise protected from
> disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute
> it by any means. Please delete it and any attachments and notify the sender that you have received
> it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a
> solicitation to buy or sell any securities, investment products or other financial product or
> service, an official confirmation of any transaction, or an official statement of Barclays. Any
> views or opinions presented are solely those of the author and do not necessarily represent those
> of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer.
> By messaging with Barclays you consent to the foregoing. Barclays offers premier investment banking
> products and services to its clients through Barclays Bank PLC, a company registered in England
> (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may
> relate to or be sent from other members of the Barclays Group.
>
> _______________________________________________
>


davehodg at gmail

Apr 15, 2012, 10:21 AM

Post #22 of 25 (2932 views)
Permalink
Re: highscalability.com report [In reply to]

On 12 Apr 2012, at 18:14, <eric.berg [at] barclays> <eric.berg [at] barclays> wrote:

> Well, finding (good) developers is certainly an issue.
>
> Here in NYC, it's very difficult to find proper Perl programmers as opposed to dabblers and scripters.
>
> One of the larger web sites here in the city was built by a great Perl guy, but as they've grown and become successful, finding Perl talent has become a big issue. I'm told that they're somewhere down the road to moving to PHP.

A good programmer can be a good programmer in any language. Good luck finding
a PHP programmer who really knows his stuff.

Also, if you need perl talent in NY, talk to Uri Gutmann.


vv.lists at wanadoo

Apr 16, 2012, 3:39 AM

Post #23 of 25 (2922 views)
Permalink
RE: highscalability.com report [In reply to]

Le jeudi 12 avril 2012 à 13:14 -0400, eric.berg [at] barclays a écrit :
> Well, finding (good) developers is certainly an issue.
>

Over the years, I have seen more than one of those being driven out of
the field by the inane management that most developers toil under. And
considering how demanding it is to be a good programmer, I can see why
they give up : you just can't have both.

On the other hand, I see scores of good developers in open source
projects (their products certainly are very good)


--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres assurances et des dossiers contentieux pour le service juridique


fred at redhotpenguin

Apr 17, 2012, 10:04 AM

Post #24 of 25 (2918 views)
Permalink
Re: highscalability.com report [In reply to]

On Mon, Apr 16, 2012 at 3:39 AM, Vincent Veyron <vv.lists [at] wanadoo> wrote:
> Le jeudi 12 avril 2012 à 13:14 -0400, eric.berg [at] barclays a écrit :
>> Well, finding (good) developers is certainly an issue.
>>
> Over the years, I have seen more than one of those being driven out of
> the field by the inane management that most developers toil under. And
> considering how demanding it is to be a good programmer, I can see why
> they give up : you just can't have both.
>
> On the other hand, I see scores of good developers in open source
> projects (their products certainly are very good)

I think the one of the main reasons this dichotomy exists is that in
open source, developers spend the bulk of their time programming. In
closed source work, developers start out doing a lot of programming,
but over time spend less time programming, and more time going to
meetings, writing status reports, and filling out HR paperwork,
killing processes on overloaded dev servers, etc. The best development
managers I've seen shield their programmers from those tasks and allow
them to get work done. There is no agile silver bullet to make
programmers more effective except giving them uninterrupted time to do
their jobs.


vv.lists at wanadoo

Apr 17, 2012, 2:46 PM

Post #25 of 25 (2917 views)
Permalink
Re: highscalability.com report [In reply to]

Le mardi 17 avril 2012 à 10:04 -0700, Fred Moyer a écrit :
> On Mon, Apr 16, 2012 at 3:39 AM, Vincent Veyron <vv.lists [at] wanadoo> wrote:
> > Le jeudi 12 avril 2012 à 13:14 -0400, eric.berg [at] barclays a écrit :
> >> Well, finding (good) developers is certainly an issue.
> >>
> > Over the years, I have seen more than one of those being driven out of
> > the field by the inane management that most developers toil under. And
> > considering how demanding it is to be a good programmer, I can see why
> > they give up : you just can't have both.
> >
> > On the other hand, I see scores of good developers in open source
> > projects (their products certainly are very good)
>
> I think the one of the main reasons this dichotomy exists is that in
> open source, developers spend the bulk of their time programming. In
> closed source work, developers start out doing a lot of programming,
> but over time spend less time programming, and more time going to
> meetings, writing status reports, and filling out HR paperwork,
> killing processes on overloaded dev servers, etc.

That is certainly a problem, I find those meetings awfully inefficient
compared to what gets done with mailing lists (eg : linux kernel,
postgresql...).

But I see another reason : I find a _huge_ part of the workload in
business applications is generated by the demands of the management
local to that organization (hence the meetings). On the other hand,
administrative tasks in general do not change fundamentally very often.

I can imagine a future when we have a few basic open source business
applications that cover 90% of the needs for accounting/CRM/case
management. Most people will just use that, and whoever has special
needs can fork it if it's worth his effort. That would greatly reduce
the need for those meetings.



> The best development
> managers I've seen shield their programmers from those tasks and allow
> them to get work done. There is no agile silver bullet to make
> programmers more effective except giving them uninterrupted time to do
> their jobs.











--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres assurances et des dossiers contentieux pour le service juridique

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.