Does this mean I have to move to California?

Which OS are You?

11:30:48 PM    comment []

There was a saying at Microsoft for a while that to be a real team you had to write you own XML parser... luckily that time has passed. However it seems today that if you aren't writing your own blogging tool, then you aren't a real blogger.

I decided to play around this in my free time this weekend... basically I wrote a set of Xml serializable objects to define my OM. Figured out the basic features, and wrote a WinForms browsing and authoring tool. I got basic browsing, editing, comments (well, 50% of commenting), and categories working.

Finally I wrote a super simple web browser experience... no pretty formatting, RSS, links, etc right now. However I did write a converter to move all my Radio feeds into my new stuff.

I have no clue what I'm going to do with this, but it made for a fun weekend. I haven't been writing a lot of code lately :(

11:05:46 PM    comment []

As Dare pointed out in his comment on my previous post, I only talked about the product bits portion of the problem... what about releasing product information early, often, and releasing control.

Lets look at two extremes - the Xml Web Services team who are working on all the WSI/GXA/etc stuff, and the Windows organization.

The Xml Web Services team is publishing their specifications (and prototypes) to the public, and then working with a working group to actually get broad approval for the spec before integrating it into the product. (Note: this is my understanding, I'm not on that team). Design by process greatly slows the development and design process down. However, it has the benefit that they will get great interoperability with other systems, since everyone will have the same lead time on the implementation of the specifications.

The Windows team isn't (to my knowledge) publishing the specs for the next version of Windows. This has the advantage that they can innovate faster, but of course their aren't the same opportunities for third parties to implement the same specifications to get great interoperability (i.e. getting a Linux version of whatever the next new thing is in Windows).

Of course, the Windows team does engage with a small group of partners to get feedback. The question always is how big of a group, and under what NDAs the discussion occurs. Some people think it is silly to have all these NDAs, but it is a way for a team like Windows to share their designs without having to go fully public - yes?

I understand both of these models to some level. The "design in public view" approach is optimized for interoperability and lack of differentiation. Basically the goal is to have a lot of people able to implement the same designs and work together. The only differentiating factor would be non-standard additions, and implementation quality. To my understanding this is the JCP model. I'd bet that a huge problem in the J2EE space is product differentiation. When you get the Sun execs telling everyone to only target "standard" features, how can one product provide value add features?

The "design in private" model is optimized for differentiation, I would argue. Your competitive advantage is your first to market with design innovations. If every feature that Office or Windows added was first publish with complete specs to the public, would those products ever have time to benefit from their innovation?

As with product bit releases, I don't think there is a black and white choice between the design in public vs. design in private models. I think you want to be somewhere in the middle. Your features that are designed for interoperability should obviously be designed in public, and you competitive advantage features should be help back and designed in private to leverage your innovation. I guess in my heart I'm a capitalist and think that people should be able to make money from the design and implementation of software - not just the servicing of software.

I do believe that Microsoft does too much "design in private"... but I also think that Sun does too much "design in public". I think that the optimal solution for Microsoft and it's customers is for them to move closer to the center.

Moderation is the key.

11:22:19 AM    comment []

Dare sent me an email reply, which I won't repost, but I would like to clarify some things that I said.

First, I believe that MSFT does release to infrequently and not early enough in product cycles. The problem is that nothing is black or white. Large products require large release cycles. Back when we first started on the .NET Framework (then called COM+, Project 42, Lightning, etc.) my team was one of the early internal adopters of the technology - and it was rough. No debuggers, lack of basic functionality, constantly dealing with GC and JIT bugs, interop that worked sometimes, etc. Releasing the product that early would have been devestating. The problem is you can only make a first impression once. If you talk to people that worked on a product like Access that had horrible performance in their first release - they did massive performance improvements, but it still took years for the stigma of the bad release to go away.

I know of projects that took internal customers too early and it is taking an enormous toll. Once you release something (in alpha, beta, or release quality) you have to provide some level of support. Even the act of a release takes weeks. You have to drive the team to reach a quality bar, get full test passes, produce redistributable binaries, etc. Doing a source release is even more taxing - you have to make a pass over the code to make sure it is ready for public consumption (you know, like no swearing in the source code! <G>).

Windows is huge. The source base measures in the tens of millions of lines of source code (I think I heard it is over 50 million?). Driving the thousands of people working on Windows to produce a customer ready (even alpha quality!) build takes time. If you ever managed a large software project, you know that not every build, every day, is ready to distribute to people.

Second, I love source code release. Personally I don't believe that the value of any company (Microsoft, IBM, Sun, etc.) is tied up in it's magic source code. I think that the value of the product is in the support, continued evolution, and innovation in the product. But again, nothing is this simple. There are huge costs to releasing source code. Yes, lots of people do it, and they have structured their organization and development processes around this. Yes, Microsoft is planning on making more and more source code available to certain customers (I read something about smart card access over the web? I really don't know what the plan is there).

In reality I think that Dare and I agree - I just think that I'm a bit more pragmatic about the costs and benefits of releases (both binary and source code). I really do want more frequent, early releases, and I would love to see more source code releases. You just have to understand that these are features - which means that other features would have to be cut.

8:09:10 AM    comment []