The Diseconomies of Scale

Discuss the feature articles on the Tech Home Page.

Do you agree or disagree with this blog?

No Opinion
11
73%
No Opinion
2
13%
No Opinion
2
13%
 
Total votes: 15

User avatar
thedqs
Community Moderators
Posts: 1042
Joined: Wed Jan 24, 2007 8:53 am
Location: Redmond, WA
Contact:

#11

Post by thedqs »

RussellHltn wrote:Utah? Assuming the great circle route (shortest path), we should pass though 4 corners, but anything north of that would be a detour. :D:rolleyes:

Metaphor Russell, metaphor. ;) But I am glad we are at least in Utah instead of Mexico on this project! :D
- David
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#12

Post by WelchTC »

mkmurray wrote:LOL, I'm trying to figure out your metaphor here with Los Angeles and New York City. Are you comparing the Church's progress of opening projects to the community to a trip between the two cities? By you saying we're in Utah, we are about a 1/3rd or 1/4th of the way there?

Thanks for any clarification... :rolleyes:
Yes, that is the correct metaphore. My estimates where simply that...estimates.

Tom
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#13

Post by WelchTC »

The Earl wrote:<favorite program="">
How does this fit with Tom's post?

Google has an interesting management methodology. Developers are free to move around projects as they wish. Developers are also free to start new projects. This allows natural selection of good ideas. A good project will get good support, and good coders. Bad projects and bad management limit their own impact. Good projects live, bad projects die. Good ideas get developed, bad ideas get fleshed out, then abandon.

This is much the same way the community development works. Good projects attract lots of people, bad projects dry up and die.

This is the way formal development is going with agile practices. Getting the community involved is just a way to start this process without radically changing the way an organization does development.
I agree with what you have to say generally. However one thing I would like to point out is when it comes to "good projects" vs "bad projects", there are some projects that are just not very fun to do (some would consider bad) but have to be done. In the open source world, those projects die. However they cannot die at the Church. Some programs have to be written and/or maintained. I am sure that Google's experience can work for many of their projects but I am also fairly sure that they have workers working on HR, accounting, facilities management, or other projects that they don't think are "good".

Great insights! Keep them coming!

Tom
</favorite>
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#14

Post by WelchTC »

gblack wrote:I think the two things to keep in mind would first be the limitations of volunteer (and/or open source) development. Time frame would be the first thing that comes to mind. Any projects that are both important and also time critical in nature probably aren't appropriate for us to help with unless you have a way of breaking it up into independent blocks so that your internal people can take over the blocks as they get to them if outside sources haven't completed them. The second thing would be successful models that already exist. Linux might be a good one. While the whole community continues to hack away on it, you'll notice that Linus still manages to retain control over the direction of the development. While a lot of derivations exist, the Church could control this either by ignoring them (maybe the Church doesn't mind if other benefit from it's code) or by licensing and agreements with community developers (maybe the Church does mind).
Yes we have thought through some of these issues already. Linux works because there is a need. Someone, for example, wants to get his video card working and has the expertise to do it. So he writes a driver. However we are a bit different at the Church in that many of the programs that we are working on are not needed by the population but more needed by the Church.

Also, remember that for those who wish to contribute to any LDS Church project, we have a license agreement that you must fill out. You can review it and fill it out here. There is not much yet to do once you fill out this agreement, but hey...it's a first step. ;)
When it's internal processes and procedures you're working with, they're a black box to most of us as we haven't worked for the Church before. Our input is pretty much limited to you asking for specific advice. Beyond that, the black box prevents us from being of much use helping you in changing your internal processes. One of the (potentially) greatest values of community input may revolve around the fact that you often don't know what you don't know. The trick is in figuring out how you can harness that.
Actually we are working on a project that we soon hope to have the community help us test. I don't want to spill the beans yet but once this project is ready to be tested, we hope to publish test plans and a feedback mechanism for you to help us with. However I agree with your comments on we don't know what we don't know. That is why I like this dialog!
A lot of existing open source projects can answer many of those questions up front. Beyond that, most of the other needed information will be determined by the control you wish to have over the results.
Exactly!


Do understand that I wasn't trying to be negative or find fault with what I said. The real point I wanted to drive at was that (ignoring community eagerness on this one) even if the Church had produced a finished product the next day, it could still be looked at as a failure. Why? Because the Church had to do it. The point is for them not to do it, so they have more free resources to dedicate to management of other projects they don't do either. My reference to the community probably already having it done was to point back to the problem the Church is trying to address with all of this - it's overloaded. I wasn't trying to crack the whip and tell you to work faster :p
I understand that you were not trying to be negative. I was trying to point out that our intent with that project was not to take it away and do it ourselves but was to have the community help us with it. We simply were (and still are) not quite ready for that. We even accepted the developer's source code that he so graciously provided.

Tom
The_Earl
Member
Posts: 278
Joined: Wed Mar 21, 2007 9:12 am

Google

#15

Post by The_Earl »

tomw wrote:I agree with what you have to say generally. However one thing I would like to point out is when it comes to "good projects" vs "bad projects", there are some projects that are just not very fun to do (some would consider bad) but have to be done. In the open source world, those projects die. However they cannot die at the Church. Some programs have to be written and/or maintained. I am sure that Google's experience can work for many of their projects but I am also fairly sure that they have workers working on HR, accounting, facilities management, or other projects that they don't think are "good".

Great insights! Keep them coming!

Tom
I thought the same thing. Google does not really seem to have the problem of getting the dirty work done. I don't have an explanation, nor have I found on from inside Google, but they don't seem to have the logical problems you point out.

I guess it may be different if your whole organization is built to write software. If your HR or FM people have coding experience, don't they become stakeholders in software written for their use? If you had a developer in the HR group, what would she do? With enough accountants and typewriters, could you eventually generate 'Hamlet'? :)

Thankfully, I don't have to know these answers, I can just throw random ideas out.

It IS clear to me that agile methods strive to shorten the distance between the stakeholders and the developers. They also strives to empower the stakeholders to communicate in ways that developers understand. I think OSS is just an easy, high profile way of letting the stakeholders charge of the development. Again, it works best in an all-software environment :(.
User avatar
bhofmann
Member
Posts: 272
Joined: Tue Feb 06, 2007 9:47 am
Location: Tulsa, OK
Contact:

#16

Post by bhofmann »

tomw wrote:When organizations open up their businesses to community involvement, they can offset many of the factors that cause the diseconomies of scale.
This blog was very interesting. I've worked at both ends of the spectrum and have seen the affects of each. I hadn't considered using community involvement in a large corporate scale. That is interesting and I would be curious to see if anyone has actually had success with it yet.

I think the biggest problem would be executive buy-in. Most executives I have worked with aren't comfortable with relying on the development community for their solutions. They feel like they don't have control and they want what they consider reliable support. They also like to see other large companies that have done it already. Of course that means everyone is waiting for someone else to do it first and it never gets done.

It would be an interesting experiment to watch the Church work through this process.
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#17

Post by WelchTC »

bhofmann wrote:I think the biggest problem would be executive buy-in. Most executives I have worked with aren't comfortable with relying on the development community for their solutions. They feel like they don't have control and they want what they consider reliable support. They also like to see other large companies that have done it already. Of course that means everyone is waiting for someone else to do it first and it never gets done.
Yes, big companies feel that they have to keep the "invented here" mind set. There is one famous example that I read about in the book "Wikinomics - How Mass Collaboration Changes Everything". In summary, a struggling gold company was having a difficult time finding more gold with the land that they had access to. The did something that was unthinkable...they published ALL of their technical, geographic, and process data on the Web and asked for ideas and suggestions on how they could find and process more gold. They got hundreds of ideas and were actually able to find more than 8 million ounces of gold from the ideas that they received. This was after the companies "best minds" could not come up with ideas to find more gold economically.

Tom
russellhltn
Community Administrator
Posts: 34418
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

#18

Post by russellhltn »

I've taken my time to respond to this, as I've wanted the think about things.

It finally dawned on me that the church has successfully tackled this problem on the spiritual side. Witness this past weekend - General Conference. The church, at considerable expense and effort, every 6 months produces 10 hours of programming where they effectively collapse the structure and Prophets, Apostles and Seventies speak directly to the membership. Usually of very basic subjects. Things found in the Gospel Principles manual. And yet it re-affirms things such that the chain of leadership that normally exists between the Prophet and the individual members has no chance of altering, "tilting" or "flavoring" the teachings in anyway. This has done a great deal in keeping us as "one church".

However on the temporal side, things don't seem to work quite that way. While we have manuals, the communication isn't as good. In many cases the members with a particular calling have banded together in self-help groups. A common cry from them is for more communication. The church has made progress in this area. This forum, and the new STS site is a good start. But then why am I reading about this exciting talk third hand from some personal blog?

My suggestion would be more talks from our leaders on the nuts and bolts of our callings. With better understanding, many questions would be answered before they were asked or at least answered before it bubbles up to a higher level. It may also cut down on the number of times that I have received different answers to the same question. It hardly instills confidence in support when that happens.

Anyway, that's my 2¢ - more communication from our department leaders. With the death of Elder Faust, there was a vacancy in the First Presidency. And yet the members knew the procedure for filling it. They didn't know who, but the only question on when it would be announced was "Saturday morning or afternoon session"? ;) That's quite a significant statement. I'd like to see the department leaders be inspired by the example shown from the top and keep everyone informed in a timely, consistent and predictable way.

Oh, and that traveler that's now in Utah - Please tell me it's a modern form of transportation and not a handcart. :D
User avatar
bhofmann
Member
Posts: 272
Joined: Tue Feb 06, 2007 9:47 am
Location: Tulsa, OK
Contact:

#19

Post by bhofmann »

tomw wrote:Yes, big companies feel that they have to keep the "invented here" mind set. There is one famous example that I read about in the book "Wikinomics - How Mass Collaboration Changes Everything". In summary, a struggling gold company was having a difficult time finding more gold with the land that they had access to. The did something that was unthinkable...they published ALL of their technical, geographic, and process data on the Web and asked for ideas and suggestions on how they could find and process more gold. They got hundreds of ideas and were actually able to find more than 8 million ounces of gold from the ideas that they received. This was after the companies "best minds" could not come up with ideas to find more gold economically.

Tom
Interesting. I'm a big fan of community involvement especially in development. Some of the best software was created by a community.
Locked

Return to “Featured Article Discussions”