Is your job easier or harder with 10,000 components?
Is your life as an Embedded developer truly better off with a thousand windows feature components and 9,000 driver components?
In NT4 Embedded there were about 250 components. With XP Embedded we gave you 10,000. Immediately after shipping the product we heard two common points of view:
1. “10,000 components!? You’re kidding me, I’m not a developer. I don’t know the difference between Winsock and the Print Spooler, how can you expect me to pick and choose the components I need for my device? You need to make this more intuitive for me, give me some more macro components to act as a ‘primer’, give me more documentation, make finding the feature easier for me.”
2. “10,000 component!? This is awesome, since I’m a developer and know exactly the APIs I require, I’ll leverage MSDN and my intimate knowledge of Windows Internals to pick and choose only the components I need. But your componentization sucks, I add the Primitive:Winsock component and it brings in some other stuff I know I don’t want.”
Would fewer components help both the scenarios above? Fewer components decreases the time to market, but can potentially bloat the footprint. Of course, further componentization would make #2 happier but #1 very unhappy.
In my opinion, the average system builder for ISV/IHV/OEMs of XPe devices don’t have an deep technical level of knowledge of Windows or any operating system in general. That’s not necessarily a bad thing, but it makes my team’s job more difficult in that we’re trying to build a product that is everything to everyone. A product that is usable by the independent contractor working out of her garage that has just a rudimentary understanding of the OS but is technically savvy in hardware. And usable by a senior developer for Windows solutions that is just as comfortable grepping through Linux source.
Is there a happy medium?
- Andy Allred
