The Diseconomies of Scale

Discuss the feature articles on the LDS Tech Home Page.

Do you agree or disagree with this blog?

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

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

The Diseconomies of Scale

Postby WelchTC » Wed Oct 03, 2007 12:42 pm

Many of you remember the "miracle of the gulls," in which seagulls saved the early pioneers' first harvest of 1848 by gorging themselves on a swarming infestation of crickets. My own experience with these "Mormon crickets" dates back to 2004 on a family vacation to central Utah.

Each year my family heads down to the small town of Hinckley, Utah, where my in-laws have a small ancestral family home. We meet there around the 24th of July and celebrate Pioneer Day with cousins, uncles, aunts, and grandparents. The home is not big enough for the whole family, so people bring down tents and camping equipment to camp in the large, shady lot. We have a lot of fun swimming in the local irrigation ditches, hunting for fossils in the nearby trilobite quarry, and panning for gold in the mountains. However, one of our favorite activities is riding ATVs and motorcycles in the hills. Several times each trip we will load up all of the vehicles and drive to a nearby trail, where we spend the day picnicking and exploring the countryside.

While on our trip in 2004 we loaded up the vehicles and headed north from Hinckley to a spot we had not visited for a few years—a place where we might find an enjoyable place to ride. As we got within a few miles of our destination, we started noticing a lot of insects along the sides of the road. These insects had large bodies, were dark brown or black, and were everywhere. Some areas were so thick with insects that they covered the road. The road became very slippery from the dead bodies of those that had been squashed by previous vehicles. These insects were, of course, Mormon crickets. The crickets seemed to cover every inch of ground. The sagebrush and cedar trees were so full of crickets that they seemed to drip from the sky. It was quite an unsettling sight.

The insects were "swarming," a behavior that is not well understood by scientists. While some theories suggest that this swarming is triggered by weather, other theories suggest that it happens when the crickets come into close contact with each other over a short period of time. Think of it as claustrophobia for crickets. The swarming instinct can be triggered when a cricket is "touched" by another cricket several times per minute over a period of several hours. Mormon crickets cannot fly, so when swarming happens, they walk like a huge army as fast as two kilometers per day. When this happens, millions of crickets on the move make it look as if the earth is literally shifting beneath your feet.

As mysteriously as this massive horde of insects appears, it also disappears. We are not quite sure why, but studies suggest that the insects eventually become hemmed in or trapped by some geographical or man-made barrier and eventually exhaust all of the food supply. Because the crickets' eggs can survive for up to two years beneath the surface of the ground, future generations of crickets are able to hatch and survive once the food source has recovered.

I recently read several research reports and studies on the diseconomies of scale. Specifically, as a company or firm grows, it will reach a point where it can no longer find economies in processes to reduce costs. In fact, the reverse begins to happen and it costs the company more money and time to produce the same products and services. The following graph will illustrate the phenomenon.




Image



As is depicted by the above simplified graph, costs drop initially as an organization finds more efficient ways of producing output. However, at a certain point (M) the cost begins to rise again and can eventually far surpass the original cost of the product. Diseconomies happen in all businesses, regardless of their industry. It can happen in the technology industry. There are three categories that explain this occurrence.
  1. Bureaucracy. As a firm adds more managers and levels, it adds more policies and formalization of processes. Problems are solved by adding structure, and the organization reaches a point at which the added structure costs more than the problem solved.
  2. Information Loss and Rigidity. With more layers of bureaucracy comes a loss of information. Ideas do not flow as easily through the levels of the organization. The company becomes less flexible and more rigid in response to increased demands upon resources. New ideas find it difficult to fight the inertia of the organization's existing processes.
  3. Agency. Employees feel less empowered to make changes. They feel like their contribution will not make a difference. Because they are restricted by existing policies and procedures that are intended to help make the organization more efficient, they become disengaged and much less productive. They lack motivation and incentives to produce. Studies have shown that employees of large corporations earn as much as 15-20% more in compensation than those of smaller companies. However, these same individuals are less satisfied with their jobs, while those who work for smaller companies achieve a higher level of job satisfaction.
When organizations open up their businesses to community involvement, they can offset many of the factors that cause the diseconomies of scale. Corporations that embrace the community will listen to what the community has to say (improving communication). They will implement some of the ideas that the community suggests (limiting bureaucracy) and will involve the community in the development of products and services (giving greater agency to employees). While community involvement can be a challenge for any organization, figuring out how to effectively involve the community is critical in today's Web 2.0 world. The Church is committed to figuring out this process. In order to accomplish the amount of work that has to be done, we need the involvement of many professionals and enthusiasts around the world. We need new ideas and insight. We need willing individuals to spend the time necessary to help us achieve our objectives.

We don't want to be like the Mormon crickets that grow until they can't sustain their growth and then begin to die out. We need to figure out how we can continue our growth in producing new products and services. We need to figure out how we can efficiently work with and engage the community. Let me know your thoughts.


Tom

User avatar
BenJoeM-p40
New Member
Posts: 42
Joined: Wed Jul 11, 2007 10:37 pm
Location: Ogden, Utah
Contact:

Postby BenJoeM-p40 » Wed Oct 03, 2007 3:35 pm

Thanks for the thoughts and insights, this is why I keeping come back here. I used to think the church was behind the times on some of these things. Then I realized it was just my stake. We had to beg to have more than once computer for each ward. The advances the church has made in the past year have been amazing. I know the Lord is behind this work and will continue you to inspire you and all of us to develop the best product to share the gospel with everyone.

Thanks again.

BenJoe

BlackRG
Member
Posts: 75
Joined: Mon Feb 12, 2007 1:31 pm
Location: Orem, UT, USA
Contact:

Scale

Postby BlackRG » Wed Oct 03, 2007 9:28 pm

Sometimes, really difficult problems on large scales can be simplified and represented by simple problems on small scales. Here's a possible way of doing that that may make the problem easier to solve:

Perhaps, the majority, or entirety of the problem that needs to be solved here can be represented in the form of a project that popped up in the forums a while back - mapping the ward members or subsets of them. Perhaps this problem can be symbolic of the problem as a whole (or in other words, look at what has happened with this project, and instead of thinking of it as "the mapping project" substitute project X). Here's what we've seen with the mapping project so far:

1. Members realized a need.
2. Members started developing various solutions.
3. Church when watching feedback from the members realized the need.
4. Church decided the need was worth developing.
5. Church asked members to stop development and indicated it would take over.

Now, as far as I can see, the only thing the Church gained from these forums in this picture is that it recognized the need.

From what you've said, the Church feels a real need to offload some of it's work and would like to accomplish that by engaging the members. All that was accomplished here was another project was added to a already heavy workload.

In order for the Church to offload work, it must let someone else do it. In this case, it means it can't take over development. So the question becomes, "How does the Church allow someone to design this project for them?".

The Church obviously has confines that it has to work within on every project to make the whole work together and insure the requirements of the finished product match the resources of it's operating environment. I would suspect that the proper roll of the Church here is to "loosely manage" the project and let it go.

A certain amount of overall design documentation will be necessary (allowable program languages/scripts, available resources, screen real estate, coding standards, etc.) - the more loosely defined while still keeping things within allowable parameters the better. If things are to strict it's going to become a discouragement to developers who are going to become more concerned about whether or not they've crossed their T's in the appropriate manner than they are the actual development.

From there, we need a sandbox. If it's a desktop program, give us source code. If it's the website, have the Church dedicate some server(s) to us (with a lot of virtualization to allow for many sandboxes per server), assign a developer account to us for access control, and give us a stripped down version of the website we can chop up or blow up however needed while coding and testing. Once we think we've got something worthy of use, give us a way to directly contact someone on the inside to check our work, and either accept it or toss it back at us with a lot of red ink for further work.

Now sure, the hardware, management hours, and what not will cost the Church some money - but man hours cost the Church some money to, and it's hoping to save a lot of those if I'm hearing you right. Also, once the initial work and capital outlay is done by the Church, think of how cheap and easy it suddenly becomes to allow the members to pursue any ol' project. Keep in mind too, that you have no commitment to that project until you've seen it and decided you like it (though there probably should be some sort of feedback up front as to the likelihood of it being used).

Now realize the process can flow both ways too. Undoubtedly, as I type, if the Church is currently rather burdened with it's workload as you seem to imply, there are a lot of good projects that exist inside the Church right now that are not being actively pursued because other more important things are. Throw them to us. See if someone will adopt them. We can hack away on them. If you like it, you keep it. If you want it changed you throw it back. If you decide you don't like it, you tell us and we quit wasting time :D

What this can also do for you is provide a back door for your own employees. In a lot of large software development organizations, it seems there's always some coder down near (or not so near) the bottom of the chain of command who feels he has some idea, change, project, whatnot that is important, worth doing, etc. but is being ignored. Now instead of being frustrated, he can take off his work hat, put on his community volunteer hat, come back with the project, and unless it's just taboo, start developing it as a community member. He gets more satisfaction than he would otherwise, and the Church gets the possibility of implementing a good idea that might have otherwise been overlooked (might provide some internal review too if the Church decides it really likes the finished results and it should have been a higher priority - it then starts to wonder why it's being done on the outside by an employee instead of on the inside - "How did we miss this?").

Back on the member mapping project - last I heard it still wasn't implemented. Given the number of different people you had working on solutions to this initially, what do you think the chances are it would have already been done by now had some approach like the above been done? I realize that some of this is going to be more difficult than I've described it. That boils down to developing internal policies and procedures. I'm not sure we can help there.

For this to work, your development internally obviously needs to be as modular as absolutely possible to make it as smooth as possible for us to interact with it while still not being a formal part of your actual team or support groups (the less non-related code that needs to be changed by us in our proposed changes, the better). This is easiest when adding features. It's more difficult when modifying them. For the website, it could be as simple as an "#include" of some sort pointed at our code and database access for any internal data sources that might be needed (if any) - thus allowing us to pretty much ignore any existing code (documented design restrictions would keep both the overall web interface (must be framed by X code, cannot contain Y code) and the database schema (these tables are read only, X,Y,and Z may be modified but only these types of data may be used when modifying, etc.) under control).

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

Postby WelchTC » Thu Oct 04, 2007 7:21 am

It is very difficult to start in Los Angeles and end up in New York City instantaneously. We have lay down the platform. As you specified, you need a sand box, you need code, specifications, etc. Those are things are what the community needs. From the Church's perspective, we need to change internal processes, we need to analyze risk, figure out how to manage the projects from a QA standpoint, etc. We have a lot to do and this work has begun.

There are several ways the community can help. Not all of the help comes in the form of coding. Sometimes we need advice. Sometimes we have very specific needs. We may involve the community in testing. We may involve the community in coding, in documentation, in translation. Each of these areas would require different ways in which to engage the community. Some more difficult than others. For example, getting advice is fairly easy now that we have a forum. Before the forum, however, it was very difficult.

We have an internal project that is specifically designed to figure out the platform, infrastructure, processes, policies, tools, and security of opening projects up to the community for development help. As we proceed through this project, we will look to the community for help in identifying the information we need.

As for the ward mapping solution...we were just out of Los Angeles at the time. Now I feel that we are in Utah on our way to New York City.

Tom

User avatar
mkmurray
Senior Member
Posts: 3241
Joined: Tue Jan 23, 2007 9:56 pm
Location: Utah
Contact:

Postby mkmurray » Thu Oct 04, 2007 8:12 am

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:

ejarvi-p40
New Member
Posts: 7
Joined: Mon Feb 05, 2007 10:10 am
Contact:

community

Postby ejarvi-p40 » Thu Oct 04, 2007 8:18 am

Here are some great ideas from the software engineering side on what it takes to succeed:

http://video.google.com/videoplay?docid=-4216011961522818645

BlackRG
Member
Posts: 75
Joined: Mon Feb 12, 2007 1:31 pm
Location: Orem, UT, USA
Contact:

Postby BlackRG » Thu Oct 04, 2007 9:04 am

tomw wrote:From the Church's perspective, we need to change internal processes, we need to analyze risk, figure out how to manage the projects from a QA standpoint, etc. We have a lot to do and this work has begun.


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).

tomw wrote:There are several ways the community can help. Not all of the help comes in the form of coding. Sometimes we need advice. Sometimes we have very specific needs. We may involve the community in testing. We may involve the community in coding, in documentation, in translation. Each of these areas would require different ways in which to engage the community. Some more difficult than others. For example, getting advice is fairly easy now that we have a forum. Before the forum, however, it was very difficult.


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.

tomw wrote:We have an internal project that is specifically designed to figure out the platform, infrastructure, processes, policies, tools, and security of opening projects up to the community for development help. As we proceed through this project, we will look to the community for help in identifying the information we need.


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.


tomw wrote: As for the ward mapping solution...we were just out of Los Angeles at the time. Now I feel that we are in Utah on our way to New York City.


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

BlackRG
Member
Posts: 75
Joined: Mon Feb 12, 2007 1:31 pm
Location: Orem, UT, USA
Contact:

Postby BlackRG » Thu Oct 04, 2007 9:18 am

ejarvi wrote:Here are some great ideas from the software engineering side on what it takes to succeed:

http://video.google.com/videoplay?docid=-4216011961522818645



Haven't had a chance to watch all of it yet, but from what I've seen so far that's an excellent resource.:)

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

Scale

Postby The_Earl » Thu Oct 04, 2007 10:00 am

gblack wrote:Sometimes, really difficult problems on large scales can be simplified and represented by simple problems on small scales.


I voted disagree. Here is why.

I think that too often 'problems' are given arbitrarily large names for small problems. An example of this would be: 'The engineering department will write software to help the organization'. At first, this really is: 'The engineering department will write a management system to track people and expenses'.

The organization is built with the second goal in mind, but with a much broader charter. When the web site, and the accounting package and the <favorite program> projects come along, the organization designed for the small goal is scaled to fit the larger goal. This does not always work well, as the original organization was never intended to fulfill the larger goal, in spite of its name.

This is evident to me with the organizational changes in software development. Agile is replacing waterfall. Test driven and user stories are replacing design docs and test-after.

What needs to be done is break 'problems' in to more manageable tasks.

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.

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

Postby russellhltn » Thu Oct 04, 2007 11:13 am

tomw wrote:As for the ward mapping solution...we were just out of Los Angeles at the time. Now I feel that we are in Utah on our way to New York City.


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:


Return to “LDSTech Featured Article Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest