myShoggoth

A better IncrementalCommand for GWT

I was pretty annoyed to find that GWT's IncrementalCommand class was essentially atomic, when I tried to have an "operation in progress" style dialog that allowed it to be cancelled the event loop wasn't given enough breathing room to actually render the full animation of creating the dialog, let alone allow the user to click the Cancel button.

I think a better solution is to subclass (or in this case create an anonymous subclass) the normal Command class and then add your own incrementality by having it add itself to the end of the DeferredCommand queue until it is done:

Command ic = new Command()
{ 
	public void execute()
	{
		if (doWork())
		{
			DeferredCommand.addPause();
			DeferredCommand.addCommand(this);
		}
	}
};

DeferredCommand.addPause();
DeferredCommand.addCommand(ic);

Where doWork() has the same semantics as IncrementalCommand's execute(): return true is there's more work to do, false if not.

The last year and a bit

Hey, I feel like bloggin!

I suspect this is due to the product I'm working on finally being at a point where I think it is usable and useful for enough of the target market that I'm willing to really talk about it and seek out feedback at a bigger scale.

What I'm talking about is VCHub, and the way we like to think about it is we're modeling the startup ecosystem.

There's a lot more to creating a successful new company than just the people in the company itself.  You have law firms, accounting firms, advisers, investors, so on and so forth.

We started with, and the core of the product still is, an online capitalization table.  This is where all the investors, including company founders and employees, are tracked and what portion of the company they own under what terms is tracked.

Most companies currently track this information in a custom Excel spreadsheet, maybe they got it from their law firm or got a hand me down from another company.  I'm not going to spend time in this post on why this is suboptimal, for many I think it will be obvious, and for those who have been in the trenches dealing with the situation the problems are very well known.

Around this core of knowing the corporate structure we also track service providers for the company and those who work with it who may not have a direct investment or option grant.

Then you add on top of that the ability to share this information with others, like the previously mentioned service providers, potential investors, advisers, and so on... and I think we have a compelling product that helps solve an area with lots of current pain, mostly in terms of how much time is sunk into managing, updating, and sharing this information.

I'm going to start to blog about the product, what we're doing, and how I'm building it.  I'm very interested in feedback on all aspects, particularly around technology and how users see the space we're modeling.

The whole thing is early yet, we have beta users and a customer advisory board (and I'm hoping both sets will read this and let me know what they think of where we're at as we go along), but others are certainly welcome to try it out and help influence what direction we take it.

Announcing LearnVC.com

Today we've launched LearnVC.com, a site to help people understand the intricacies of startups, startup financing, the venture capital world, and related subjects.

I'm working on this with my brother, Jeff Boardman, who brings the domain expertise and is running the business, acquiring and creating the content, and maintaining the blog.

My responsibilities are on the more technical side, particularly around the example web widgets and the beta capitalization table that is a fascinating part of the future of the idea.

The cap table itself is a GWT application and is only client side for right now.  I've been working on fleshing out the features and making it handle more and more financial instruments and interesting terms that are used in the VC world, once that is closer to completion I will work on saving the data, sharing it with others, etc.  If you have feature ideas please do not hesitate to let us know.

Everything is a bit rough, but we're at the point where getting feedback and making changes based on that is much more important than creating something in a vacuum and hoping we got it right.   We'll add more content, features for the cap table, and the example widgets in the articles (which use the same code as the cap table).  We're starting the long road of rapid updates and improvements.

No Coasting

I was going through my morning routine today when it struck me that there's a parallel between the Talent vs. Skill idea I wrote up a while back and how I approached grooming and hygiene for the longest time.  I figured if I needed to work at it then it wasn't real, so I took poor care of myself in terms of health (and fitness) as well as grooming and hygiene.

I've made a big shift recently to realize that you are what you work to become, and what you're born with is only the raw materials you have available, not the predetermine end result.

I spent a lot of time with a close friend while I was in Colorado, and one of the things that I'm so impressed about with her is what she's made of herself, how hard she's worked at it, and the incredible results.

Similarly, when I look at what my wife has consciously worked on for the last few years to become, and the progress she's made, I'm blown away.

I'm much earlier along, still trying to determine what I want to make of myself, but a big change is that I'm consciously doing so, and not coasting anymore.

This is a reason why I think consulting is a great fit for me in general, and in particular right now.  I can't coast, I need to impress my clients every day.  At a big company, it is far too easy to coast.

Time to redouble my efforts about consciously working to make myself better at what I do for a living, which is happily one of the things I love to do.  No coasting.

Google Kicking Butt, Taking Names

Google just announced Google App Engine, and certainly (driven by Robert Scoble) that has been running like wildfire around the blogosphere.  It solves some very interesting problems, and does it in a slick way, but it also creates some questions.

Google App Engine solves the following problems that I can see:

1. Scalability
2. Deployment
3. Authentication
4. Management

And it solves these in great ways that make sense, leveraging the resources that Google can bring to bear on the problem, and preventing the developers from having to reinvent all the infrastructure.  Awesome.

Let's look at the problems that Google Web Toolkit solves:

1. Cross-browser compatibility
2. Lack of compile time error checking in interpreted languages
3. Sophisticated handling of layout
4. Architecture for creating custom controls and AJAX behaviors
5. Asynchronous round-tripping to the back end correctly
6. Sophisticated caching
7. Image bundling
8. Integrated best practices for handling browser history (back button support)

As you can see, these frameworks, both from the same company, are basically non-overlapping in the problems they solve.  Imagine a combination, where you can easily create a GWT application and deploy it to App Engine!  In some ways GWT is solving the client side of the big picture problem of writing web apps, and App Engine is solving the server side, with GWT doing some of the heavy lifting to allow seemless communication between them.

This is nirvana.  Until they integrate them, Google has a big hole in their developer story.  Once they get that tied together it will be amazingly difficult to compete against it.

New MacBook Pro!

I finally pulled the trigger on getting a new laptop (haven't bought one for myself for about 10 years, all since then have been work provided).  After agonizing and reevaluating and weighing options for about four months I finally decided on one of the new MacBook Pro 15"s.

I'm going to blog stream-of-consciousness on my impressions.  First my background: My parents bought a Mac back when they first came out, and I grew up playing with it.  I got myself a PC as soon as I could afford one (early in high school, I think) and ran a BBS, programmed PASCAL, etc. on it.  I grew to dislike the Mac because it wasn't really something you tinkered with, and all the fun stuff was happening on the PC or the Commodore 64 or my brother's Amiga.

In college I went hardcore into the whole UNIX thing, and played around with Linux pre-1.0 kernel.

My first job out of college was at Quark, working on Quark Publishing System.  I arrived there my first day and was informed I was a Mac programmer.  Although I became quite good at using them, I grew to hate them as only a programmer back in those days could.

Alrighty, so, first the anticipation.  I left work early and was absolutely giddy picking it up.  I haven't looked forward to opening a toy this much in a long time.  The packaging was very well done and solid, pulling it apart was like unwrapping a present.  Very few components, which I think is genius.  A couple cables, a small book, and the laptop.  That's it.  I don't feel like a packaging warehouse threw up in my office.

Booting it took a little longer than I expected, but once it got going... It makes the Windows OOBE experience look like a pile of puke someone has taken a little spritzer can of water to, to make it look shinier.  Holy crap.

I'm at the Welcome screen, and it has: To begin, select the country or region you're in, then click Continue.  And it only shows 6 countries, with a Show All check box.  So much better than the standard Exhaustive List By Default.

The Wireless screen is similarly useful yet minimal.  It just shows you the list of networks it finds (and Other Network), and asks for a Password.  That said it did a horrible job with my very complex WSA2 key, and I had to join a WEP network first.

Can I skip the Apple ID/Registration crap?  I don't see how to avoid it, even though it says on the screen that "The warranty for your Apple product does not require you to register the product."  I can't find a way around this.  Is Apple trying to piss me off?

Everything was incredible with the setup until they started pushing their services and registration and didn't give me a way out.  Now I feel sleezed.

Communication and Ownership

I've been thinking about how software is built, and why small nimble teams seem to outperform massive teams on a regular basis, both in terms of getting interesting products to market and mind-share.  You would think that a bigger company with more resources, more stability for its employees, and significant infrastructure should be able to move faster, but it is taken for granted in the industry now that that isn't the case.

I believe it comes down to two core issues which have huge effects by themselves and also interact with each other to amplify those effects: Communication, and Ownership.

Communication

Software development is all about effective and efficient communication.  The requirements needs to be created, turned into a product design which then needs to turn into technical design, that needs to be turned into code and tests, the results of the tests and other usage are turned into bugs which are then triaged, investigated, and resolved.  One the appropriate level of quality is achieved, the product is shipped.

A Team of One

In a team of one, there is no communication overhead.  That one person determines what problems the product will solve, how to solve them, how to implement that solution, tests it themselves, and fixes problems that meet their own quality requirements.  When she feels satisfied that everything is good to go, she releases the product via whatever channel is appropriate, gathers user feedback and fixes issues, releases updates, etc.   In the case where she is also the only user, she can determine precisely what is worth fixing and how fast that needs to happen, and act on that.

In that degenerate case, there can be no miscommunication or misunderstanding... well, unless there is some sort of multiple personality disorder thing going on.

If you get beyond that, the cost of communication is now added.  The other extreme is an everything-by-committee situation:

Everything By Committee

A large marketing team goes out and gathers customer requirements for a potential product.  They gather their results, negotiate with upper management, go back and forth many times to make sure everyone is in agreement.  There is a VP review, where the busy executive who in theory was being kept up to date on everything going on throws everyone a curve ball, because in fact he had not been keeping up to date on anything.  He's very busy, can't read every email, is scheduled 10-12 hours a day in meetings and doesn't have time in the day to prepare for them (unless they're with management higher up the food chain than him, of course), so the entire proposal is actually brand new.

Yes, I could go on a rant about executive reviews and their cost alone, but I won't.

You can see where that's going, let's skip ahead.  Specs are created, and now they need to be reviewed by assorted management, every other PM on the team, every tester, every developer.  In this spec review, the way to make the time worthwhile is to try to differentiate yourself from your peers by explaining, mostly, why none of it will work.  Due to miscommunication and misunderstanding, the spec itself will never fully address the product requirements (which never fully address the real customer problems), and will fall short in some places and add extraneous stuff in others, and only a few of these issues will actually be found during review.

Some developer is assigned to implement the spec, so they create a technical design, and... have to get it reviewed by every PM, tester, and developer on the team.  See above.  The technical design will naturally not implement the spec exactly, it will fall short in some places and go beyond the scope in others.  Some of those issues will be found in review.

The tester takes the spec (and technical design) and creates a test plan, but again the communication overhead means it will get farther away from testing for what should have been the product requirements in the first place.

The rest is left as an exercise for the reader, but the main point I'm making is that the more communication that has to happen at each step of the process, the more miscommunication and misunderstanding will warp the product.  This is the classic game of telephone, where a simple message at the beginning of the line gets warped beyond recognition by the time it reaches the end.

When considering team structure, processes, tools, policies, etc. the overriding concern should be the total team communication overhead.

I can readily tell when a team has major communication issues but doesn't know how to solve it, and they often work hard to make it worse.  Any time I see a team declaring parts of the day or certain days of the week for No Meetings,  I know they're getting totally bogged down in over communication.

When people reflexively add more process (forms, Excel spreadsheets, approval processes, etc.) because of misunderstandings or miscommunications that caused major issues in the past, and what they're actually doing is making the whole thing worse by adding to the problem that caused the issues.

My theory on why Pair Programming seems to work so well (when it does): because it simplifies the communication structure for that part of the team.  You rarely have Pair Programmers who constantly need to check in with other parts of a larger team, they are a self contained unit and the point of it is to have them there to double check each other, so everyone else leaves them alone.  It isn't that it is ideal, it is that by creating an accepted pattern with a relatively low communication overhead cost all the more expensive and hazardous models are avoided.

So it comes down to this:  Pick the team size, structure, tools, processes, and policies that are the best fit for the product you are creating, and make those decisions based on minimizing the communication overhead overall.  There is no one correct answer, there is no one perfect team size or set of processes, it requires skill and experience to know what is best, and even then it will likely change over the course of the project.

Making changes is fine, as long as the act of making those changes doesn't create more communication overhead than the changes themselves are meant to fix.

Effective, efficient communication is crucial to a successful product, but most of what happens is not even close to that.  Minimizing overall communication overhead and focusing energy on what is truly valuable maximizes the productivity of the whole team.

Ownership

I'm going to say something heretical now, hopefully I won't get blacklisted from the industry for it:

Passion is overrated.

More to the point, passion is used in most cases as a substitute for what should be the most important thing, a well designed structure of ownership.  In many cases the people you're hiring don't have any real say in what's going on, but are expected to do great things anyway.  That's not really possible, and yet managers have seen people do it anyway, even in environments that are poisonous to initiative and creativity.  Those who rise above it and make it happen are extra passionate about what they're working on (or working in general), and so the manager naturally assumes that hiring passionate people is the win.

That's not the right fix, the best fix is to fix the poisonous environment so even people who aren't Type A personalities can make the same impact.  This is pretty classic W. Edwards Deming stuff, you're looking at a problem and blaming the people for all your woes, but it isn't the people, it is the environment/process.

Microsoft Classic was an organization that empowered the rank and file to make the critical product decisions, and the job of the management was to clear obstacles for them.  This meant that the responsibility was clear: if you own this feature, you own it.  You can get input from others, but the final decision rests with you.

If you don't actually own the decision, then your customer is not the product's customer, but rather the person or people who do own the decision.  You're trying to make them happy, not the end user.  If you combine this argument with my views on Organization Entropy, you can very quickly see what direction this takes any product.

Interaction

The interaction of these two issues only compounds both.  A bad ownership model will cause significant communication overhead as the person who has the responsibility but not the authority attempts to convince those who have the authority what the right decision is.

When the ownership model is particularly bad it can create a need for everyone involved in even the most minor details to feel like they need to be directly involved in the decisions for those details.  This can get worse when someone is passionate, but not informed.

Finally, the ownership model directly dictates a lot of the communication that is required to create a product, and what patterns that communication will have.

The Beauty of ExitProcess()

I had to reinstall my home computer's 64-bit XP Pro because it had become essentially useless (seems to be doing much better now), and in the process I found out that recent installers for Windows Live Messenger don't install on 64-bit XP Pro.  They just don't.

I know the dev lead on that team, so I gave him a piece of my mind on that.

Instead I'm using Windows Messenger from the XP SP2 install.  I worked on that code, I was the lead developer for that release on that product.  I made the painstaking modifications to Windows installation to get it working, ported the code my team had been working on for months and months, went through the assorted nightmare overhead of being a part of that mammoth release.  We spend more time than I like to remember combing through every line of code by hand and with automated tools trying to make sure there was no security bugs.  We changed and fixed a lot of code to make that happen, the devs working with me kicked butt and took names.

I logged in and things worked.  Lots of features missing relative to Windows Live Messenger, but it is usable.  The people I IMed with tonight don't know I was on a much older version, and didn't care.  I watched the working set for it, and felt a lot of pride and how tiny it is an how few resources it takes away from the actual primary usage of the computer.

Then it reminded me of a pet peeve that I have about traditional desktop applications, and as I related this peeve to friends I realized I should write about it.

Why does any application on the planet ever take any time whatsoever to shut down?  There is one good reason: the user has some data that needs to be protected.  That's it, that's the only reason.  You should make sure you save the data, let them know what's going on if it is going to take more than half a second, save their data, then get the fudge out.

If there's no data, just. shut. down.

I've worked with teams that demanded that we ask permission from servers that could be on the other side of the planet with heavy packet loss whether we were allowed to shut down.  No, just get out.

I've worked with people who want to make sure that the process exits by having the program execution perfectly work its way until the end of the main function, and slide off the end in the glorious sunset of well designed code.  No, just get out.

I've worked with people who want to do some amount of memory sanity checking even on the retail builds that are sent to customers, rather than just the debug internal builds.  No, just get out.

Program startup should be instant (I'm talking to you, Adobe) and should be all about getting useful UI in front of the user as quickly as possible.  Microsoft Office apps are awesome at this, so good you don't even notice it anymore.  Launch any Office app next to an Adobe product.  Hell, launch all of the Office apps next to Photoshop at the same time.  Twice.

But that is relatively understandable (only relatively) next to taking any time whatsoever to shut down.  The user wants you gone, do the minimum cleanup you can get away with and then call ExitProcess().  If you're doing any more, you're sacrificing the user experience for... what again?

No, just get out.

How Microsoft Should Re-Invent Itself

I really wanted to spend more time researching and getting details and financial reports and so on to make this post, but a certain *cough* deal has forced my hand.

All of this is my personal opinion and in no way reflects any views of my current or past employers, and in fact I would expect many or most to disagree wholeheartedly.  I'm not in any sort of position to do more than talk, not even influence.  This is me.  Okay?

Microsoft needs to turn into a spin-off machine.

There are a ton of reasons for this, I'll get into as many as I can remember and think of, but the core is that Microsoft's current way of doing business is fundamentally not working, and the recent announcement of the bid for Yahoo! for $44.6 *billion* could be the nail in the coffin.  MSFTextrememakover has a wonderful item-by-item post on why it is a horrible idea.

More importantly to my way of thinking, this deal will increase organizational entropy in a big way.  And that's death.

On the other hand, spin-offs are a wonderful way of resetting entropy, mostly for the company being spun-off, but also for the spinner.

The core of the idea:  Retain and invest in the two cash cows, and use their profits to fund a program of:

1. Spinning off all the existing businesses outside of those two.  Try to figure out what products, suites, and current businesses would work the best together.  Find the right people to lead them (not in terms of internal politics, but as business leaders).  Packaging them will be difficult and time consuming, but I think it would be startling how much value there is.
2. Incubate new ideas and products, focused on bringing them to the point where they can be spun off.  Lots of thought needs to go into how to find people who are ready to be executive management teams for these new spin-offs.  If the idea can't stand on its own as a separate company, cut it and reinvest.
3. There is still plenty of room for acquisitions in this world, but the mindset is totally different.  Now the idea is to buy complimentary businesses to work with incubated products, shoring up their weaknesses before spinning them off, or to dedicate enough resources to take a great idea, repackage it, add significant value, and then spin it back out into the world.  Almost a VC or private equity type of a role.

In fact, that's a great way to think about it in general:  Microsoft becomes a private equity company where the funding comes from the two most successful products ever.

Pros

• Career advancement, and reward paths that don't involve massive bureaucratic politics.  You can help create a new, successful business, and get rewarded with options and new opportunities when the business is spun off as its own company.
• Huge recruiting power due to the above.  You're not hiring into a faceless corporate black hole, you're being recruited into a very entrepreneurial company that is all about incubating and spinning off new businesses.
• By changing the focus of the company, you change the culture.  Things have coagulated, everything is about safety and step-by-step career advancement.  In a more entrepreneurial culture, taking risks is expected and rewarded.
• Most importantly, in this world the reward is tied to the business, not to the chain of command.  You're working to create a successful new business that you want to be spun off, the big rewards come from being a part of that success, not just convincing upper management that you're better Partner material than your peers.
• Get away from the myth of synergy.  A lot of time, money, and careers have been wasted trying to figure out a way to tie everything Microsoft does into a nice package that will magically make a huge multiple more money for the company than the individual pieces.  This has mostly failed, and will continue to fail, and the few successes will not even pay for the costs of the failures.
• Increased focus on the bottom line in all aspects of the business.  Every new business is seen in the light of its potential to create a new, separate company, rather than how it fits into arbitrary goals or organizational politics.
• Managing the company's billions is now an exercise in return on investment, rather than a shotgun of attempts to recapture the old Windows/Office magic.

Cons

• It really hasn't been done before that I'm aware of, it isn't clear the model will actually work.
• The entire management team and organization for the company is ill suited for this kind of a change.
• The company's goodwill and reputation are both pretty well in the toilet, and it would take some time before acquisitions could be made at favorable costs.  Right now it seems like their only leverage is overpaying enormously for what they want.
• It isn't clear that talent the company has attracted/retained over the past half dozen years or so would thrive in an entrepreneurial culture, nor is it clear the culture could make such a huge change.
• Probably plenty more, that's all I can think of immediately.

Weird Performance Review Min/Max Thought

A weird thought occurred to me this afternoon, mostly because it is irrelevant to me right now.

In some performance review systems you're up for a promotion on a relatively rare basis, and the way that decision is made by management factors in a lot of non-performance gunk.  For instance, let's say this is a big company and you can internally transfer around.

• If you're new to the team they probably won't give you one of their precious promotions, they'd rather reward those who have been there and stuck with them for a while.
• If you've recently been promoted, naturally you're much lower priority.

Along the same lines, when giving out the prizes they're more likely to reward those that have been there for the entire review period, rather than someone who joined in the middle.  Plus the rewards tend to be worse in the review cycle right after a promotion.

Thus, the absolute best time to internally transfer is immediately after a promotion, preferably at the beginning of the review cycle.  The two major reasons why you wouldn't be promoted are both true (recent promotion and recent team move), and both being true is unlikely to cause the downtime to last longer (the recent promotion probably puts off the next review longer than the new team does, but maybe not).

The two major reasons why your next review would be less rewarding are also true (just been promoted, new team).

The reason why teams don't give promotions to new team members is to reward people for staying with the team, but the side effect is that the best reason to leave a group is because they did give you one.  So the promotion is a way to keep people at a company, but not with a specific group at the company.

This assumes, naturally, that you have interest in leaving the current team.  Promotions are rare opportunities to use an internal transfer to your advantage, in other situations it is pretty much a bad deal.  Probably a better idea to do an external transfer, and then come back later with broader experience and at current market rates.