Fog Creek Software
Discussion Board

How would I move Mount Fuji

1) I would hire a lawyer (corporation), seek VC, hire manpower (setup offices etc.).

2) Hire PR.

3) Hire some top ex-CEO's, ex-top managers, and other high-payroll people with different names. They should come up with plans. Meet and agree to 1 plan. (Insert PR+VC campaign here).

4) Outsource the work...

5) PR again.

Sunday, May 4, 2003

Mount Fuji is a volcano, is it not? Couldn't some well placed explosions cause it to erupt? What about drilling a hole in it's side so as to relieve pressure aimed upwards. Then it would explode in the direction of my choosing, hopefully away from the populated areas, which is presumably why you're moving it in the first place.

If someone in Las Vegas bought it and I was hired to move it to Vegas, I would just cut off the top few hundred feet and move those "brick by brick" (I would chop it into bricks) and move that... Then build a mechanical mountain below it that shot sparks out every once in a while... All the distinctive characteristics of Mt Fuji, none of the danger.

As for the Mt Fuji in (Japan is it?) well, it would still be potentially deadly, it just wouldn't look like Mt Fuji anymore.

Do I get the job?
Sunday, May 4, 2003

1. I'd get half the money up front.

2. Sub-contact the "work" to Penn & Teller.

3. Make off with the cash.

Sunday, May 4, 2003

Nick, you definately don't get the job.
Sunday, May 4, 2003

How much of the Mount Fuji must be moved? 100% or is 1% ok?

I would leave the dirt in place and just change the official maps. Rename some other mountain to "Mount Fuji".


Sunday, May 4, 2003

Everything in this world is relative.

I would keep changing my co-ordinates, that way Mt. Fuji would *move*:-)

Prakash S
Sunday, May 4, 2003

Isn't Mount Fuji already moving at breakneck speed as the rotating Earth orbits the Sun?

Ged Byrne
Sunday, May 4, 2003

And as the universe expands. And slowly as tectonic plates shift. If you're going to get that anal about it, and question every single request, I don't think you're the right person for this job.
Sunday, May 4, 2003

I believe North Korea has the technology needed for me to buy in to achieve this contract, at the same time could I interest you in an entirely depopulated country north of the 48th parallel?

Simon Lucy
Sunday, May 4, 2003

If this were Middle Earth and I were Gandalf, I would just get the trolls that hang out here to move it for me.
Sunday, May 4, 2003

Scenario: Rich Guy Joey wants Mount Fuji, which is why I'm moving it.

I comission an artist to get me a good image of Mount Fuji in all weather. I replace all of Rich Guy Joey's windows with LCD screens and cameras, with Mount Fuji dynamically inserted into all the views.


I change Rich Guy Joey an insane amount, because, mountain moving and all. Pocket the cash, run like hell, and hope Viewsonic warranties last long enough to cover my retreat ;)

Mike Swieton
Sunday, May 4, 2003

Is it me or is anyone else wondering what problem they want solved by moving it and is that the only way to solve it?

Sunday, May 4, 2003

B# - yes, that's what I was getting at in my first post.
Sunday, May 4, 2003

B# raises an interesting question, and I find myself in a dilemma...

On the one hand, when someone asks to move Mount Fuji, one should ascertain the business reason for moving said mountain, since there may be an easier/cheaper way to achieve the desired effect.

On the other hand, it is presumptuous to assume you know more than the person asking, and when presented with a specific request for a concrete action, you should simply address the problem.  (To know how this feels from the customer point of view, just go ask how to do something specific on Usenet and watch half your answers address the why instead of the how)

To be honest, I don't know the answer. I think it's 50/50 - half the time the client will appreciate your help defining the problem, and half the time they'll be annoyed that you're wasting their time, since they've already spent money defining the problem; you're just here to solve it.

So in that case I'd have to say "use a third table"


Sunday, May 4, 2003

Mine is not to reason why, mine is but to be at work from 9 to 5 or get fired?
Sunday, May 4, 2003

Look at it this way - if the problem is "how would you move Mount Fuji?" then asking "why would you want to?" is scope creep.  ;-)


Sunday, May 4, 2003

First of all - please excuse my bad English. It is not my native language, and now I'm VERY drawsy because I drove about half of the night, returning from a nice holiday in the mountains.

So here is my reply to the question about moving that mountain or volcano:


Aww, c'mon! It's a really stupid question.

I thought about it for about half an hour - but I am a software developer, not an architect or mechanical engineer. These are the people who can answer this question, not me. I can hardly take such a question seriously.

I have been interviewed by Microsoft, and they NEVER asked me to solve this kind of stupid puzzles.

They asked us questions and asked us to write code and to review already written code and find bugs - NOT to solve stupid puzzles.

The reason I failed their interview was that I was VERY drawsy (like I am now). It is interesting that now I'm glad that I failed the interview and did't go to USA (I live in Eastern Europe), as now I have my own small company, I make pretty good money, and have a normal 40-45 work hours per week schedule (I understand that at MS, they kill themselves working - so much that the wifes of MS programmers are called "MS widows" - and this is not a joke).

But it really was a nice experience - meeting people from MS and the MS Office team.

Anyway, when interviewing someone for my own small company, I would never ask them such a STUPID and worthless question.

I usually employ people to do specific tasks (for example: write Delphi components), and I give them a VERY HARD, but similar, task.

I also ask them to show me code that is already written by them (larger pieces of code, even if they are only parts of an application), and I review it carefully, in order to make sure the code they write is organised.

Anyway, if someone doesn't have already written code to show me, I don't hold this against them, but just give them the hard task to work on.

If they can complete the task very well (from about 20 people, only one or none usually complete the task), I hire them "on a trial basis", for one month.

In that month, I discover if the person is disciplined or not, if he/she gets frustrated quickly and abandons the problem, etc, etc.

I can easily test technical knowledge during the interview.

However, technical knowledge is not all - the person must also be disciplined and hard-working, must not give up easily, etc.

These personal qualities can not be reliably be tested in an interview - ask anybody if he is disciplined and hard-working, and he or she will look into your eyes, smile, and say "of course". This can easily be faked.

So I'm looking for people who:

- can perform the task

- are disciplined, hard-working, and don't give up easily

I still admire MS, but think their employment interview puzzles == crap.

Michael K.
Sunday, May 4, 2003

Michael, now I know why MS didn;t hire you :-)

Prakash S
Sunday, May 4, 2003


Michael K.
Sunday, May 4, 2003

If you move it, make sure it's within the camera's view:

Maybe move it closer to the cam.

Please don't move it during the summer, it's suppose to be beautiful (anyone seen it?).

Good luck

Monday, May 5, 2003

Hum, I not really sure it is such a bad question at all.

I remember some years ago when a client asked me in to develop some data entry forms.  Of course, each data entry screen had to be developed in code. (very much like using clipper or dbase where you actually have to code in the field position  by hand and editing logic also).  I then asked how many data entry forms do we need. Well, it turned out to be  about 50, or 60 data entry forms.

Golly, that is interesting. I then thought that we could take the cost (budget) of building about 40 forms, and I could build a screen builder system that would let the company build forms. Thus, for the cost of about 50 forms, every form after that would essentially be cost free, since then the company could build their own forms using my form creation system (and not have to use a developer). Of course, as a developer the thought of programming 50 data entry screens was really boring. However, building a screen gen program was very exciting. Not only that, chances were that we really needed about 75 screens. Clearly, my out of the box thinking here paid off big time. I built the screen gen for about the cost of 40 screens, and the rest was gravy. Not only that, but many more appcltions and forms were built since the cost was now very low. In fact, non programmers could now build data entry screens. We wound up with well over 200 screens!

So, what does the above go to do with moving a mountains? Well, just about everything. All software projects are like moving mountains. If software is too easy, then it usually does not have much value does it! When software gets to be tough, then a standard approach is not the answer.

9 out of 10 companies would have just started coding that data entry screen, but I said no, I will not! I said for the same cost we can get something far far better.

Microsoft always looks for that better way. So, while most companies had products like FoxPro/dabase, when ms came out with ms-access they had a much higher level of abstraction, and split out the data components (Data Access Objects – DAO). This means that over the years, they could plug-in new object models like ADO and not throw out the product (all those other old systems had the data and code tied into the same code system). MS in their brilliance split this out of the product, and that is why I can use access 10 years later). They did not just solve the ONE problem at hand, but took a engineering approach to many problems. They wanted to move mountains, and they did that by thinking well beyond the problem of just moving one rock.

So, how do we move a big rock sitting out in the front yard? Well, we call in a bunch of heavy lift cranes, and a big heavy rock truck and move the stupid rock. Ok, so, most people now know how to move a rock, or how to develop a data entry screen. However, as the problem gets larger, then a standard approach does not work. So, coding a data entry screen, or using a rock hauler is not the solution when the problem gets real large.

So, now, how do we move the mountain?

Further, it sounds to me like a very mechanized approach is the only reasoned solution here. Thus, we probably have to attack this problem as a manufacturing problem, and not really a problem of moving a single mountain. In other words, we need to set up a circular type rail system between the old mountain location, and the new mountain location. We need to manufacture a LOT OF machines that can take a manageable sized piece of the mountain, load it, and then move it to the other location. We might even purchase, or setup a manufacturing plant JUST to make those machines that run on a set of rails, and can move a chunk of the mountain. So, the solution here is manufacture those machines. Doing that, we can move the mountain, and in fact, we can do it for a reasonable cost also. Of course, I am assuming rails, and we might want to clarify if we need the mountain in north America for Disneyland. (hey then we build a custom boat loading system, but we still use lots of those rock grabbers and putters.

So, to me, this can be a very good question. You need to make just one form, then heck, just code it. You need to make a 100 forms, then a simple coding solution is not the way. The same goes for moving one rock, or a mountain.

I remember having dinner some years ago taking about the human genome project. We were discussing the laborious testing and how long to map the human genetic structure will take. My first comments that one MUST SPEND a HUGE AMOUNT of time automating this process, or it will take forever. The one group was content to get up every day, and do this manual tests day after day after day. Just like that company was hiring develoers to code forms every day. The genetic group concentrated on automation, and spend a lot of resources on not even doing some genetic testing until they could develop and manufacture machines to automate this project. Well, who do you think won the race for the human genome project? (the folks to automated the process of course!). In fact, they even started selling machines to the other team that was being left in the dust! They thought about how to move a mountain, the other group just started grabbing rocks!

So, to move a mountain, you can not just pick it up, and you can’t just hire a few rock movers from the yellow pages due to the size of the project.

There was several attempts at tunneling under the English channel. The final solution was to build some real nasty custom tunneling machines, as conventional tunneling approachs was not workable due to the size and scale of the project.

So, how do you approach large projects, or difficult tasks Vs small tasks is a fabulous lesson.

I think the question of how to move that mountain is a very good question, as many software projects entail a straight labor intensive approach, and others need some need new technologies and designs to be built BEFORE the project can be even feasible.

Yea…sure good question.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, May 5, 2003

And oh, by the way, we need to store the mountain, since the BOTTOM of the mountain must be placed in the new location first. Hey, kind of like a…

See, I told you this was a good question!. It really is like a software problem….

Albert D. Kallal
Monday, May 5, 2003

I think Albert just saved us reading the book:) , good points Albert.

Prakash S
Monday, May 5, 2003

If you're looking for a programming analogy, it's basically a Towers of Hanoi problem.

Monday, May 5, 2003

Master Kangan pointed to the mountain and said to Daichi: "You speak of mind over matter -- then let's see you move Mt. Fuji."

Wordlessly the young disciple pulled the shoji screen across their view.

The Master smiled and put the shoji back into poistion. "You had to use your hands."

Silently Daichi closed his eyes.

<credit>Anonymous Zen mondo, slightly changed for the subject matter</credit>

Monday, May 5, 2003

"Further, it sounds to me like a very mechanized approach is the only reasoned solution here..."

I don't see how the entire paragraph that follows the above statement has any basis in reality, but I guess you're serious...

Ignoring the fact that the time to construct the supporting infrastructure alone would approach the decade mark (if you were lucky enough to have no financial or political limitations), there is simply no way for a team of humans to reassemble the mountain with any degree of accuracy.

No matter what kind of system you use to keep track of the pieces (which are going to be much tinier than what you seem to imply), the project is destined for failure. Analyzing the system to place the zillions of pieces correctly is not something the human brain could handle in a reasonable time span. Developing a way to computerize this analysis would add to your initial startup time by an order of magnitude (software people don't have a good record with being punctual), and wouldn't really help since, in the end, humans still have to feed the computer its input and then implement its instructions. Finally, we haven't discussed what to do about any of the living things found on the mountain - are we allowed to just replace them? Is that possible in the new environment? Do we have to save any of the animals?

Even if you didn't care about accuracy at all and just wanted to move the entire mass of dirt from one area to another, it's not feasible. You have a ridiculously large supporting infrastructure which will have absolutely no use once the project is finished (unlike your data entry forms example, this project should eventually terminate), so good luck getting that approved. But more importantly, you will also lose a good chunk of the mass in transit - ever try to sweep a little pile of dust into a dust tray? You have to do it like five times to get all the dust you miss when you sweep. Multiply that times some uncountable number and you'll find that your new mountain will be noticeably smaller than the old one. You may think I'm nitpicking, but if you're not going to be accurate, then where do you draw the line?

Bah. The question is ridiculous. The real answer is:

"What we have here, Bob, is a customer who has read some trade magazine about how mountain moving is the industry's next great paradigm. We *could* try to move the mountain, but it's not cost feasible; we just don't have the resources. Nevertheless, we don't want to lose a customer.

"We need to convince him that he doesn't want to move the mountain yet, because he'll suffer the consequences of every other company who's bought into a new idea right away - he'll have to be the guinea pig, and others will benefit from his mistakes without incurring any cost. When software companies release Version 1 of a product, people who jump on board right away are taking a chance that they picked wrong - if that is the case, their investment is sunk. The better choice is to rely on current technology and wait to see if the new product matures - if so, we can feel better about investing money into it.

"It's the same thing with mountain moving. We should leak the Fuji idea to the press, make it sound like we really want to do it but don't have the resources. Let Oracle move it - Larry Ellison is crazy, he'll jump at the idea. Then we can watch and learn from their mistakes - once they've finally figured out the best way to move a mountain, we can copy their infrastructure while avoiding the mistakes, and we'll just pick a bigger mountain. With a proven system in place, we can attack Mount Everest and still complete the project in less time, showing up our competitors for a fraction of the cost.

"In the meantime, Bob, I would tell him that we have an excellent strategy for capitalizing the resources he already has on Mount Fuji. Our team will start a buzz about the mountain moving plan, but for now, let's focus on starting a project that generates money based on what features the mountain already has.  There is TONS of money just sitting on the mountain, you just have to know how to extract it. We can put together a solution that will do that.

"Data mining. Web service."

That is how you move a mountain in the software industry.

Dan J
Monday, May 5, 2003

awesome, we have just seen the inclusion of vaporware:-)

Prakash S
Monday, May 5, 2003

Something I learned the weekend:

Moving Mount Fuji Status Report

1)Moving Mount Fuji: Complete

End Report

90's the Network Is The Computer
00's The Status Report Is The Job

Daniel Shchyokin
Monday, May 5, 2003

Let's get all Matrix-like philosophical:  What is Mt Fuji? 

If it's an abstract being and not a collection of dirt, I'll do what a computer sometimes does -- make a reasonable copy and destroy the original one.

Monday, May 5, 2003

            What have you been smoking this weekend? How on earth is the fact that Access is a relational database and not a hierarchial or flat database the result of Microsoft being brilliant? The whole point of the relational data model is that it is independent of any implementation. 

                Once the hardware got fast enough to deal with the overload of a relational database all customers were asking for it. It's no more an intellectual feat on MS's part than General Motors choosing to build cars instead of pony traps.

            Huge buildings, such as the Temples at Abu Simbal, have been moved and reassembled stone by stone. And I very much doubt that they even used computers for it in the 1960's.

Stephen Jones
Monday, May 5, 2003

If the mountain will not come to Mohammed...

Monday, May 5, 2003


I think you've cracked it.

Have you applied to Microsoft yet?

Ged Byrne
Monday, May 5, 2003

How on earth is the fact that Access is a relational database and not a hierarchial or flat database the result of Microsoft being brilliant? The whole point of the relational data model is that it is independent of any implementation.

Ah, ok…

No, a database can be most relational and still be dependent on a particular implementation. There is no connection, or “reason” that you have to split out the data engine from a development environment because it is relational (or not relational). Heck, I don’t even think that there is one vendor of sql that is compatible with another anyway..

My whole point here had nothing to do with a relational database. The point was that MS SEPARATED the development tools (form designs, reports etc) and the development language (VB, well, ok VBA) from the data engine. The data engine was a SEPARATE system. That is what was brilliant.

Products of the day like dbase/FoxPro etc did not separate the development environments, and programming language from the database engine. They were one and the same.

Since ms-access had a separate data engine, then a very important abstraction took place. Thus, ms-access could not assume that the data was on a file. In fact,  you could not assume even where the data was coming from (perhaps a server half way across the world). That is also why ms-access did not have record numbers where as other products of the day did. Products like dbase had record numbers because they were file based, and simply calculated a fixed length for each record.  (the 5th record for 100 bytes reocrd is at 500!).

Further, the dbase (and other IDE’s) were tightly bound to the concepts of a particular file. That file concept was actually part of the programming language.

Ms-access was separate from the data engine.

Thus, MS was free over the years to introduce new data engines, but keep the code and the remaining stuff the same. So, all of a sudden I could use the same VB(a) code, and my data was now on sql server. Products like dbase never made the jump to client server, because it had a limited design (and the language/code/engine were one and the same).

With a lot of effort, and a large re-design, MS did bring this abstraction to Visual FoxPro, but it was too little too late. (dbase never got ODBC to my knowldege..and it was not compatible with the exiting code because you can’t assume record numbers anymore in ODBC!).

People tend for forget how important these innovations are. The same goes for com objects in windows, and that was a another big step for MS. (so is the .net, and the concept of shared com objects across the net).

These things are key technologies, and they are VERY forward thinking. MS really does do a good job in this regards, and it is  these types of choices that are very much a large reason why they are so successful. They bank on key technologies that will make a difference. (and it did for products like ms-access).

Some of the stuff of .net technologies is just starting to pay off, and for the future, it will do so well as probably land then back in court! Real smart stuff here.

If MS had not made that abstraction and separated the data engine from ms-access, then access would not be recognizable today from when it started out 10 years ago.
Things like record numbers and how you access data do not even make sense or apply in today’s modern systems.

10 years is a good run for a product, and it still is full of life, and they are adding XML support to ms-access now. Good design here.

The fact that MS hires all these weird forward out of the box thinking people really does make a difference. It seems the competitors to MS need to learn this lesson.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, May 5, 2003

Actually, it's more a matter of Microsoft's marketing prowess (and large store of cash) then its 'innovative thinkers.'

Knowledgeman (a semi-popular DOS-based competitor to dBase) had a separate data-layer from its user interface long before Access.

A lot of Microsoft's 'innovations' are common sense to the part of the industry that knows more then just Microsoft products.

Monday, May 5, 2003

For sure other companies realized the concept of breaking out the data engine from the code system. (I remember k-man, and even migrated a k-man project to pick).

Also, Remember that ODBC is a Microsoft invention that virtually the whole industry adopted.

Thus, even for products like K-man to take advantage of client server, they had to use MS’s ODBC technology.

ODBC was is just another example of the MS’s forward thinking.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, May 5, 2003

Knowledgeman was the most advanced PC database but suffered from lack of marketing cash and the company that created it MDBS Inc of Lafayette, probably creates the best database engines in the world.

Simon Lucy
Monday, May 5, 2003

Actually, k-man did this before ODBC. They were accessing either their own data engine or SQL Server back when MS's SQL-Server only ran on OS/2. Their data engine was also available for use in other programs (as a library).

I doubt if k-man was the only product to do this - it's just an example of MS's innovating by adopting what other people have already done.

It also shows that an outstanding product will go nowhere without good marketing while an OK product can be a big success with outstanding marketing.

Monday, May 5, 2003

I was composing my prior reply even Simon posted his (so I'll do 2 in a row).

I worked for mdbs (note, it's all lower case) for about 18 months during one of their 'bust' cycles.  I was on the consulting staff, not the product development staff.

mdbs suffered from a couple of major problems. As Simon pointed out, one was a lack of cash. More importantly, it lacked the business talent that Ashton-Tate had that made dBase a top product. Part of the problem was that the staff was entirely home-grown (when I was there, all of the company officers had started working for them straight out of college) and were mainly programmers that didn't know the business side.

It also took what little cash it had and did a dot-com style 'spend all our money to look big' and expanded to 5 offices at one point. I was there to help close the Dallas office and move it to Chicago (the last office outside of Lafayette). When I left, there were strong rumors that Chicago was next and everyone would be back in the Lafayette headquarters.

They did have great technology but they lost the desktop database market to dBase and their server database (known as 'mdbs' back then) was very powerful but it wasn't relational - at a time when the relational model was taking over the world.

Monday, May 5, 2003

Move Mt. Fuji?  What touches the heart of a mountain?  Obviously if long, mournful ballads of masterless samuri would do the trick, the mountain would be in Tahiti by now.

Monday, May 5, 2003

Microsoft "invented" ODBC like Al Gore invented the internet.

According to Microsoft's own website:

"The ODBC API is based on the CLI specifications from X/Open and ISO/IEC."

In other words, it's standard MS "embrace and extend".

Phillip J. Eby
Monday, May 5, 2003

Microsoft didn't invent ODBC... actually a company in Raleigh NC called Q+E Software invented something called the "Q+E Library" which predated ODBC and eventually worked with Mircrosoft and other companies to standardize ODBC

Simon Garfunkle
Monday, May 5, 2003

I would hire an intern from a community college @ minimum wage, declare myself project manager, and then delegate the task to the intern.  If the project doesn't succeed, then I'll blame it on the intern and fire him afterwards while collecting my project management consultation fees.

Monday, May 5, 2003

Reminds me of a story I heard passed down from my one of my managers.

A new manager is hired, and finds in his desk 3 envelopes, prepared by his old manager. Along with the envelopes is a message to only use them when he's in serious trouble.

So the new manager finds himself in trouble and opens the first envelope. It says "Blame the previous manager." Oh yeah, what a great idea, so he goes to his meeting and explains how he's just cleaning up the other guy's mess.

A while later, he finds himself in trouble again, so he opens up the second envelope. It says "Reorg" so he fires all his old employees and hires on consultants.

Finally, he find himself in deep doo doo again and opens up the last envelope. It says... "prepare three envelopes."
Tuesday, May 6, 2003

I would use geological dna from the hot springs of Mt. Fuji to create a nanometric clone of the ecological system to be reproduced in 3-D for reprocessing in memory convergence SD-70_Arch Astro-Projection Portation.

Far Out
Thursday, September 11, 2003

Have the faith of a mustard seed.

Monday, January 5, 2004

Has anyone asked what "Mount Fuji" actually refers to yet? If I ascribe the name "Mount Fuji" to my laptop, the solution is easier to perform than to describe. It seems to me that the real problem lies in determining what the question is really asking of us. The wording of the question misdirects us into making assumptions about the question's intent. While it seems the How is important, the What is really the most pertinent question. If I was asked "How would I move a block?", it's more difficult to make assumptions about what "a block" is, so most of the discussion would revolve around answering the What (ie. How big is the block? Is it a block of cheese or a block of flats?).

Paul Bernays
Thursday, January 29, 2004

*  Recent Topics

*  Fog Creek Home