[mrmaddog]

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 memory, and thus the feature needs handle far more edge cases than it would have if this was an earlier-implemented feature. I'm not saying the overall time to develop segment-tuning would be shorter, in the long run had it been developed first, but the perception of development-time for this feature would be shorter (since any segment tuning edge cases that you ran into while writing an application would be considered part of the app's development time, not segment-tuning's development time).

I'm sure that if Mr. Gates had implemented FAT at a later date, he would have needed a much longer plane ride.

[wtallis]

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.

[mrmaddog]

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.

[scott_s]

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.

[DenisM]

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.

[mrmaddog]

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 this sort of interaction. Our entire OS was built so an agent would be resilient to changes in another agent, and this modularization means there is very little "spaghetti code". However, when you are building a feature (say, a new routing protocol), you have to be extremely conscious of how it interacts with everything else: various reliability features (i.e. Stateful switchovers), configuration features (saved configs, public APIs), resource contention (TCAM utilization), etc. etc. If that new routing protocol was the first thing we implemented on our switch, it would be a complete breeze. In the context of other features though, this becomes a more intensive project (though in codebases without proper modularization you'd find this task "herculean" as opposed to "intensive").

[jaggederest]

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)

[judk]

That is true of immutability languages like Clojure, O don't see how that is possible for a mutable dynamically typed language like CommonLisp

[ars]

> I am a huge fan of code modularization

These days that's no problem. But back then computers were slower and memory much tighter. Making clean interfaces to integrate things made the code too slow and large.

On the other hand, projects were smaller, so there was less need.

[astrobe_]

Or maybe not. The modern version of segment tuning is cache friendliness. Also, with modern virtual memory, function layout may be important in order to minimize page faults.

[rasur]

Completely unconnected to the discussion, and excuse the incursion, but your (Aristas) Switches _rock_. Got 8 at work - loving the 10G interfaces.

Thanks, carry on. ;)