According to this, Gates did some of the design, but Marc McDonald, employee #1 at MS, helped with the design, and did the coding in 1977: http://en.wikipedia.org/wiki/File_Allocation_Table#Original_... Like a lot of old stories remembered after-the-fact to make a point, it seems that the truth is more complicated.
Thanks for pointing this out. It's all too common to overlook employee contributions to projects.
I think the point of the story wasn't proper attribution, it was a way for Gates to prod people to work faster.
I think the real lesson here is that every time you add a feature, you are adding development overhead to every other feature, leading to exponential development time. I'm sure if segment tuning was one of the first thing to go into windows, it would have been much simpler to implement. However, at later stages in the development you have to account for how different, already-written applications are loading their me…
I don't think segment tuning is the kind of "feature" your lesson needs as an example. Segment tuning is just a link-time optimization phase. The people doing manual segment tuning were just producing an ordered list of the already-written functions, to be used as input for the linker. These days, it would be implemented as a completely automated process using profile-guided optimization. It's not something that you can do early in the project and get it over with, because any time you do anything to change the call graph of your code base or the size of a compiled function, you need to re-tune.
From 12BitSlab in article's comments > I don't mind if billg gets a little arrogant at times. One merely has to look at how he wrote the ROM code for the Altair to realize his abilities. > Also, ALL of the concepts embodied in modern tablets and smartphones were "invented" by billg when he wrote the code for the Tandy 100. Things like "instant on", data stored in non-volitile memory, small productivity apps, continue…
He had the fastest algorithm for pancake sorting for a long time. Not the coolest thing, but still pretty impressive and not just can code.
I had a manager that would repeatedly use this type of remark. We had this particular application that on one could touch without breaking something. It was always a mess. He would often remark "I wrote the whole thing over a weekend, why can't you guys make a tiny little change without breaking it?" One day I finally got fed up with him and replied "Because it's the quality of work you'd expect from an entire applic…
I once worked with a founder who would always pull that kind of garbage: "I wrote [simple software with no dependencies or integration requirements] in [N] days! Why is it taking you guys [M] months to write [complex software relying on several 1st and 3rd party libraries, a component that needs to work within a large, old legacy system]?
I think the real lesson here is that every time you add a feature, you are adding development overhead to every other feature, leading to exponential development time. I'm sure if segment tuning was one of the first thing to go into windows, it would have been much simpler to implement. However, at later stages in the development you have to account for how different, already-written applications are loading their me…
I'm confused by your comment. "Segment tuning" isn't a feature , it's a process . One only did it for performance gains. That one would have to do it for performance gains is a result of the fact that code segments were loaded in 64 KB chunks. It's another instance of trying to take advantage of spatial locality to achieve better performance.
I think the real lesson here is that every time you add a feature, you are adding development overhead to every other feature, leading to exponential development time. I'm sure if segment tuning was one of the first thing to go into windows, it would have been much simpler to implement. However, at later stages in the development you have to account for how different, already-written applications are loading their me…
I don't think segment tuning is the kind of "feature" your lesson needs as an example. Segment tuning is just a link-time optimization phase. The people doing manual segment tuning were just producing an ordered list of the already-written functions, to be used as input for the linker. These days, it would be implemented as a completely automated process using profile-guided optimization. It's not something that you…
Ah, I didn't realize this was done as a manual process back then. I assumed the engineers were working on an automated system to do the segment tuning for them, and that system was the new "feature" that Mr. Gates thought the engineers were wasting too much time on. Feel free to re-read my above comment with "segment tuning" replaced by "some other feature." Thanks for the correction.
Another possible conclusion from your analysis is that a proper architectural separation of concerns (which could allow one to bang out code like he's still on that plane) has not been practiced in Windows, and by the time Bill was offered the opportunity to code something in Windows it was already hopelessly entangled.
Not exactly. I am a huge fan of code modularization, but what modularization offers you is the ability to decrease the exponent (i.e. to be devTime^1.01 instead of devTime^2). Some features though (including segment tuning, from the sound of it), will touch a ton of other features regardless of how well you modularize your code. I work at a networking company (Arista), and a lot of the interesting problems come from…
pg's whole thesis for lisp was that it reduces the increasing time of modifying larger codebases to o(log n) rather than o(n^k) or o(n) (n being size of codebase)