Incremental Blogger

Over my years of Robotics and software development I’ve come to a couple rules when it comes to dealing with and interpreting things going on in the real world. They are, if you will, the Three Laws of Real World Development:

1) Sense what information you want directly as opposed to trying to develop an algorithm to infer it. The latter is usually more error prone than you and the computer would like. If you want depth information, for instance, use a sensing system that can measure depth directly, rather than say using stereo images or even a single camera where you have to interpret from the data depth information. Same goes for position information, or timing, or altitude, or weather conditions, and on and on.
2) Whatever you can sense directly, try to leverage its data as much as possible. Not everything you want to determine about the real world is sensible. Sometimes you have no choice but to try to extrapolate what’s going on. This may be because there isn’t a sensor that can sense the information you want or possibly even if there is it’s not practical to use if there is. So whenever there is something you can sense directly, try to exploit this information as much as possible. If it scales well–that is is useful in many ways–you’ll have a winner.
3) When you do have to interpret information about the world, reduce the range and keep things simple. What do I mean here? Try to find the bounds of what you can reliably sense and stick within this range. Sometimes people will tell you things are impossible, and more often than not they are right–particularly about the general case. But in specific cases they are wrong and some approach will work. Try to find what that input range is and what approach works well within it. Complex solutions do have their place, but often in very narrow areas and more often than not a simple solution will suffice over a smaller range.

I’ve been thinking quite a bit about where I’d like to see Windows to go down the road–particularly from a programmer’s perspective.

Although I’m still trying to think through precisely which APIs/SDKs I’d like to see, I have come to the conclusion that for all practical purposes the future of Windows’ API and the .NET Framework are woven together. It’s not just about what I’d like to see in Windows–it’s about what I’d like to see in Windows and the .NET Framework collectively.

As a long time C and C++ developer, I’ve grown to accept that I now live in a C# world. With this behind me, now it’s time to think about where I’d like to go with all of this.

Here’s my starting point: Whatever “it” is, I want to see higher and higher level SDKs. The web is a great illustrator of the value of this–something that was always true even on the desktop, but something no one quite had the time to get around to. The web reminded us of the importance of decoupling and how much more we can all get done if we choose the connection points right. Why is higher-level programming more “doable” on the web? It isn’t, but the connectivity makes it shine. That’s the motivator. That’s the facilitor.

Look at all the mashups–using classic think about how we could have written these on the desktop, would we have ever gotten there? I don’t think so. When it comes to graphics intensive apps, such as mapping tools, most efforts would have crumbled when it comes to low-level graphics implementations. Same goes for image handling. And then there’s the whole file system issue. And deployment decisions.

Anyway, back to Windows and the .NET Framework. It’s obvious to me that Windows development is never going to lead anymore–in the broader sense. There’s too much legacy stuff that Windows has to honor. Adding anything new is risky and I can appreciate the Windows team saying no to the latest new ideas. Rightly they’d doubt its real value. The result? Windows is very unlikely to have any new leading edge technologies within it. They have to be proven first. And then if they are “proven,” I can see the team arguing that “Hey look at how far you got without your great app or tools being merged into Windows, so why should we fold them in now because 1) you didn’t implement them the way we would have and 2) it would increase our testing like you cannot imagine. In other words the Windows gatekeepers are all about saying “No.” From a user’s perspective it’s for our own good. Sorry early adopters.

And this is where the .NET Framework comes in. It should become the future of the Microsoft API if you will. Notice I didn’t say Windows here, I’m referring to the future APIs collectively as something that Microsoft makes available for the browser, for Windows desktop apps, for cell phones, for MIDs, and yes, even for the Mac and so on.

For the future of the .NET platform I’d like to see more and more high-level APIs. For today’s world, there should be lots of RSS feed support, OPML mindedness, Facebook APIs, and so on. Yes, Microsoft is going this direction, which I think is the right path. But what about tomorrow? I’d like to see APIs for connecting apps, similar to OneNote’s shared session feature. I’d like to see vision SDKs, including face tracking, face recognition, and gesture reco. I’d like to see neural net APIs, text searching tools, dictionaries, grammar analysis of sentences, and on and on and on. Some of these could be desktop focused. Some could be web focused. Some could be both.

Why am I suggesting to expand the focus of the .NET Framework? Because as I described the other day in a post, the world is about connected devices and communication. And you can’t have effective, powerful communication, if everything is locked into one platform. Silverlight is beginning to pave the way here, but there’s so much more that’s possible and feasible.

Give a developer a vision SDK and they can do some clever things. Give them a framework where they can process 30 live video streams, stitching them together in real-time, indexing major events all automatically, generate thumbnails for quick and easy access, well now you’ve really changed the game. To pull this off there’s going to be huge infrastructure challenges, yes. But imagine what developers can do if you keep climbing the abstraction layer? With good connectivity and good processing power, there are so many exciting things that will become practical for let’s say one or two developers to do–which has always been a magic number in creating new, exciting solutions.

So where does Live fit into all of this? I see it as a component of .NET–at least the tools part–and then by definition the low-level functionality. Search, for instance, is a very high-level search API or query engine. Same goes for Virtual Earth, and on and on. Likewise, ad databases, page scraping, context analysis, tagging, semantic analysis, news threading, and so on all have primitives that would be part of the Microsoft Framework. Now all of these might have end user front ends–I guess that’s where the Live team fits in. It would take care of maintaining this portion. But everything else would be developer oriented. It would be about creating very high-level APIs.

Yes, the future is about connectivity and very high-level SDKs–at least for the majority of developers.

All weekend long I saw Twitter and Twitter message talking about impending market turmoil and a recession in the US. And this got me thinking. How might a further economic downturn affect web services, such as Google Doc? After 10-minutes of head banging, I come away with the view that these types of services will do even better. Why? Because they have lower costs to entry and are cheaper to maintain.

Does this mean Office is going to slide into oblivion over the next couple of years. Absolutely not. However, an economic shakeup is very likely to shake up the “PC” market further.

As much as I love developing dekstop-style apps, experiences will keep moving online and onto smaller and smaller devices–both which require rethinking of what a good app is.

I’ve set aside Sept 15th for ths year’s Desert Code Camp, which will be held once again at the University of Advancing Technology.

Now that a date has been set, the real fun can begin–deciding on the session topics. Like last year, anything is fair game. Just submit your idea on the Desert Code camp page.

Hmmm. Maybe an iPhone session? Or how to support touch on an iPhone AND UMPC?

I’m getting ready for a pair of conferences next week. Well not exactly. I’m officially attending Microsoft’s Mobile & Embedded Conference next week in Las Vegas. I’m particularly looking forward to the Robot competition that it has. Can’t miss the Robots.

I’m also going to un-attend Mix07. As I’ve blogged about before, I wasn’t fast enough to sign up for Mix07 this year. It sold out. I tried getting onto the waitlist, but I was bumped. Likewise, I tried to get a press pass, but I didn’t make the cut there either. But that hasn’t deterred me. I’m going. As you may know I’ve been focusing much of my UMPC and Tablet PC development efforts around some new Microsoft technologies in large part because I like the trend in languages–particularly XAML. With WPF and now Silverlight both supporting XAML markup, there are knew development models that’ll become practical. At least that’s my hope. We’ll have to see. That’s one reason I wanted to go to Mix.

But not getting into Mix07 doesn’t end my thirst for the latest trends in WPF and Silverlight. That wouldn’t be the startup spirit. Instead, I’m doing the next best thing–I’m going to be hanging out in the hallways at the conference and talk to whomever I can. I’ll broadcast at least some of it live via UStream.tv. More details later. It should be a blast.

I’m no fan of Visual Studio 2005. For me, it feels bloated. Start with the Start page. I appreciate what it’s trying to do, but come on, I have a browser for browsing. Likewise, I must need help, because I finally gave up trying to figure out how to best configure the help on the several different machines I develop on. Again, I realize the Visual Studio team is trying to give me flexibility, but ugh. And then there’s the sluggishness and my seemingly instinctive ability to configure the UI so it flickers like mad when I program. I know. I know. If I spend a couple minutes I can get the UI to not flicker. I don’t. I’m lazy–scratch that. I’m too busy working. I just don’t want to spend time getting the tool just right and then do the same on this other machine I use and then this other and you get it. I guess this is partly a problem of my own creation. I use too many machines. My programming is a little bit here and a little bit there. I often have two or three projects open at once. My machines are getting old. Too slow for the new software. And my expectations are too high.

Don’t get me wrong. There are some things I really like about VS 2005. The refactoring in C# is nice. It’s a good start. In fact, for C# development it’s not all that bad. It is annoying as all get out that I can’t modify the code when debugging all of the time, but I manage to survive. I’m sure if I think about it, there are some more things I like about Visual Studio 2005 over its predecessors. Thinking…

Actually, part of the problem I have is that I’m programming with Microsoft’s latest technologies. So I’m using beta software. I know better than to get up tight about beta stuff, but I guess this demonstrates I’m human. No source code generator here. One of the biggest problems? Visual Studio 2005 crashes. Lots. Sometimes it does an amazing job auto-recovering. Simply amazing. It’s almost like the VS2005 team knew the app would tend to crash and went out of their way to do a great job of recovering your work state. I presume most of the crashing is due to beta stuff I have in my dev environment. I do know of the four machines we use for development here, all crash at least one every other day. Sometimes more often. It gets old.

Beta software also very likely contributes to the sluggishness in VS2005. Yeah, I shouldn’t complain. Take WPF development, for instance. The not-yet-ready support in VS2005 for WPF is unbelievably slow. And it’s just not the performance, which is awefull. I just don’t use it. I’ll use Blend. I’ll hand code. I’ve spent a little time trying to figure out why. That’s probably best left to another post. I hope the Visual Studio team is doing some similar thinking. Looks to me like there is some code worth dead-endng.

With this background, I bet you can see why I’m very interested in hearing about any developer tool announcements at Mix07 next week. I’m ready for a little less pain.

The way I look at it is that developing with Microsoft’s latest technologies is in flux right now. That’s understandable. The core technologies themselves are still being baked. Silverlight hasn’t even been officially released, for instance. And quite frankly, we’re all learning too. The language teams. The tool builders. The programmers. The designers.

I do think the overall language direction is a good one. It’s just…..I wish, I wanna, I need. You understand? Right?

In a welcome about face, Microsoft has decided to make Expression Blend and Expression Web available in MSDN subscriptions. Soma Somasegar makes the announcement. A welcome decision.

Initially Microsoft was intending to separate out the new Expression design tools from the developer resources. However, in my mind it seems that there’s going to be greater intermingling of “classic” developer tools and the new generation of design tools–especially on the web, although the trend goes much further.

I also firmly believe that a successful tool of the future is going to melt away the distinction between designers and developers. Either the designers are going to do more developing–or the developers are going to do more designing. The result will be greater efficiency either way. That’ll be the key to success.

Robert McLaws would like more information about the next version of Windows. Microsoft says not for now–at least publicly.

With Vista just recently coming out of the starting gate all this talk of the next version of Windows may make good headlines, but it’s plenty early for public discussion on Microsoft’s part.

Now as for us Windows customers–especially for those of us that have been using Vista for the last several months in beta and release form–I know there are plenty of people like me that are building their wish list for what they’d like to see in the next version of Windows. That’s fair game.

So here’s part of my list (in no particular order and which is subject to change):

What I hope Microsoft sees is what I see: Namely that mobility needs to become an even greater part of the Windows experience. What do I mean? Take power management. Vista has made improvements in power management (such as an improved design in how apps are allowed to veto the shut down sequence), however, if you want an even bigger impact on how usable a notebook is, there needs to be instant on. Students need it. Doctors need it. People on the go need it. Whether instant on is only possible from sleep or a cold boot, I don’t care too much, but it’s not there yet. It’s closer, but there’s still room for improvement.

Another area of improved mobility I’d like to see is within apps such as Media Center. What about supporting channel settings for different locations as I travel about?

I’d also like to see smarter management over network connectivity. This will become even more important as broadband radios are built into more notebooks. What happens when I’m at a conference and try to get connected? What kind of connection should I get at a coffee shop? Which one is the fastest? Which one is the safest? Which one is the easiest to connect to? Which one is the fastest to connect to?

Thirdly, I’d like to see better ad hoc collaboration provided for applications so that students can work in groups in a classroom with their notebooks or Tablets, so that my kitchen contractor can share design mockups effortlessly, and so on.

I’d also like to see the browser enhanced in the next version of Windows–after all the browser is where many people spend a majority of their time. I’d like to see the programming model and capabilities extended for developers. I’d like to see SDKs and technologies that further help to build apps which at times rival even rich client apps. I’d like to see minimized load times, better accessibility, improved caching, integrated spell and grammar checking, support for Windows browser experiences on more platforms, and more.

Along these lines I’d also like to see online services tied in with the next version of Windows–such as an online backup/archival and sharing service. Whether its to save remotely digital copies of someone’s wedding photos in case of a fire or natural disaster or to give easier access to a student’s homework (or keep it away from the chewing dog) as they move between home, school and work, it seems there’s plenty of opportunity here.

Another area ripe for improvement in the next version of Windows is the “it just works when I install it” experience. As closed or semi-closed computers such as notebooks and Tablet PCs become more standard, the collection of drivers that come with Windows becomes more important. In fact, I’d like to see Microsoft commit to supporting out of the box all the drivers in every mainstream notebook for lets say at least two years prior to the launch date of the next version of Windows. Desktops are another matter because there’s so much variability. Particularly for upgrade purchases this is a big deal. For a desktop I realize I might have a driver issue. For a notebook there’s not much I can do with it anyway as a consumer. Therefore this is what I expect: If I upgrade my copy of Windows on a Tablet PC and my Tablet PC is supported, all the built in devices should work. Period.

This is my Windows wish list so far. I expect it’ll keep growing and adjusting as I continue to use Vista over the coming months. (Oh my, I almost forgot my pitch for Windows Movie Maker to support cut shots, for instance.)

Steve Yegge gives his thoughts on the “Next Big Language” (NBL). An entertaining read.

I’d add to his list of next big language features:

* The next big language is going to win because it increases productivity. It’ll enable more people to do more. Most likely it’ll expand the notion of who a developer is.

* I think Steve underplays the likelihood that the next big language will enable the computer itself to play a bigger role in what it means to be a programmer. This means potentially more tools, increased ability of the computer to analyze or generate code itself, as well as higher levels of abstraction for the human that increase the burden on the computer.

I also think Steve overplays the impact that a big company plays in the success of a particular computer language. Sure a particular language might fly high for awhile as a company promotes its next great language, however, if it doesn’t provide great value, the language will languish. The advantage a big company may have in promoting a language is not simply its market strength, but its skills and resources in communicating the value of a language. Size is not simply the key. The value has to be there.

(Found via Robert Scoble)

Here’s a Technology Review article about Charles Simonyi and the challenges in improving the productivity of programmers. Found via Dave Winer.

When it comes to programmer productivity, the article neglects one fact about software development: The amount of change a programmer can make to a design in one day exceeds that which they can make in other ways–so maybe that’s why it looks so hard.
Of course, for a class of apps, there’s no doubt in my mind that programmer productivity can’t be drastically improved. The evolution of software development will see to it.

As of today, Windows is 21 years old. It launched November 20, 1985. Windows has come a long way since its first iteration.

I didn’t pay much attention to Windows until 3.0 came out. A friend of mine tried to get me into Windows development during 2.0, but I couldn’t see the value for the apps I was writing. Most of the people I knew wanted fast, easy-to-use DOS apps, and not programs written that they’d have to run under Windows. By Windows 3.1 though, I’d made most of the transition though and as networking slowly improved, more and more of the business customers stepped forward wanted to run Windows. As a PC developer I rode the wave of porting DOS apps to Windows throughout much of the early 90s.

Adobe announced yesterday at their Max conference that they will be funding startups that leverage Adobe technologies (particularly Apollo) to the tune of $100 million.

What’s Apollo? It’s a new, cross-platform runtime technology that takes Flash and HTML (as well as other common browser scripting languages) out of the browser.

Investing in targeted startups is a great idea–particularly while inexpensive investments are still “acceptable.” With this fund, Adobe should be able to spread their money quite effectively. Even at $250K per company per year their investment strategy could have significant impact. Heck, $50K can make a huge difference for a one or two person team early on too. What Adobe has to resist though is the urge to place large bets on a small number of companies. This may make it easier to manage the investment portfolio, but it’s unlikely to have the impact they want.

I think this is a good move on Adobe’s part. Most traditional VCs aren’t going to be interested in encouraging Adobe’s cross-platform technology per-se, but an Adobe fund can. Adobe is interested not only in the success of the startup they invest in, but also the adoption rate of their technology–by developers and end-users. This is not the case with a typical VC. A VC doesn’t necessarily care if a product is implemented using Java or the .NET platform or now Apollo. They want the company to pick what makes sense. Now Adobe wants the same thing–however, if you pick Apollo, then they’ll be interested, potentially financially.

CNet: Winternals now part of Microsoft team..

Robert Scoble: Google’s geek-friendly “Do what you want for 20% of your time” isn’t “real” research friendly:

“Googlers point to their 20% time as proof that they are investing in research. I say that’s bullhockey. Why? Most of the Googler’s I know are pulling 70 hour weeks. Saying you get 20% of a 70-hour week to spend on what you want is like telling me I get to spend Saturday doing what I want.”

Part of the problem here is definitional. Companies often lump product development under the R&D moniker, however, most research groups (with a capital ‘R’, such as Microsoft Research) are quite different. They often focus on long term projects that may not make economic sense right now. I’m guessing that most Google employees spend their “research” time working on projects with much more immediate concerns and current practicalities.

As an engineer it’s important to stay focused on near-term practicalities, however, it’s also quite valuable to keep your eye on the horizon–whether that be six months or six years (or more) ahead.

In fact, when I work on a project I often spend some of my time on “side” projects. Why? First off, because it often gives me a different perspective on things. Sometimes it gives me a better appreciation for the value of the current solutions. At other times it leads to new features or products. Either way it gives me a chance to learn.

You see, generally I learn best from doing. So these side projects–often worked on at night or on the weekends–are my hands-on learning time.

As an engineer, though, one key thing to keep in mind is that most of the time a company cannot leverage these extracurricular projects. No matter how good they are. This can be true for any sized company. I imagine Google employees run into this too.

What kind of projects do I pick to do on the side? Sometimes I start with projects that will augment the main product line. This gives me a chance to learn more about the current system. However, I also keep an eye out for projects that are being burdened by process. What do I mean? If there’s a strong need for something new, but it appears that it’s going to cost too much to do, sometimes things grind to a halt and the need goes unaddressed. One strategy around this is to look for different ways to solve the problem or maybe only try to solve a portion of the problem. Or maybe try to solve the problem in a completely different way–leveraging different technologies.

Here are some of the 20% projects I’ve worked on in the past.

I once worked on a workgroup-based financial application at a small company that was selling enough to pay the bills, but couldn’t make traction against its competitors. In addition, customers were increasingly demanding the product suite move up to the client-server world. It was going to take a substantial amount of work to pull this off though–so the change wasn’t made. Instead the product was updated incrementally. About this time the Internet was gaining traction. We talked about creating an browser-version of the app, however, none of the customers wanted it. The technology was too new and there were too many unknowns. So what did I do? I spent my off time working on a browser-based version. About the time I had it done a customer was willing to fund a client-server port. So while we did the port we made sure to support an Internet version of the product as well. In the end, the customer opted for the Internet version and the originally spec’d client-server product suite never saw the light of day. Not only that, the browser-based version became so successful that the founders of the company were able to sell their business, retire and pursue their life-long dreams.

Things don’t always go this well, however. At another company, they were struggling with managing a code-base which they had purchased from a third party. The app was showing its age and didn’t do what the sales force needed. The company was betting big on this products and was trying to expand the product and grow it competitively at the same time. They tried many different things. Adding developers. Adding testers. Adding more sales. Nothing gained traction–yet the sales force was indicating that there was strong customer interest. So I tried an off-hours project to see if I could help out. At first I started with small apps, which more often than not I’d find out later that others had done already, but yet they didn’t really solve the problems at hand. Sales still lagged. Then around one slow holiday season I decided to ratchet it up and give it my all. I started building a new system from the group up. I started fresh in C++. The legacy code was all Turbo Pascal. I built a system that was compatible with their current client-server system modernizing the UI as well as adding a CGI-proxy and a browser front end. It took a lot of work and involved some feature sacrifices, but after a couple months I had a running prototype. The result? No one in the company wanted to align with it. It was an unknown. Most people were very concerned about getting laid off and they didn’t want to take any chances. It was all quite understandable. When you work on off-process projects, you have to be willing to accept that others won’t want to use it. You have to be satisfied with all that you learn.

In another situation I consulted for a small startup that had been struggling. It had consumed about $10 million in a relatively short period and was trying to focus better as it re-organized. When I joined they were taking a project that they’d built for internal use and were going to commercialize it. Their technical problem was that their code base was very Windows centric. The sales force told them they needed a cross-platform solution to be competitive. Unfortunately, they couldn’t quite manage to port their system. Once they started spec’ing out the changes they’d need to make and all the testing that would be needed, the cost would be too great and it would take too long. So how did I use my out-of-process time to help out? At first I started building tools for testing. This gave me a chance to understand better what the system did and the various file formats and protocols. After a couple months of this, I began my off-time project in earnest. Over the next month or so I built up an engine that replicated theirs at a functional level–only it was cross-platform (although I kept Intel-byte ordering to avoid having to change any file formats or protocols). From this point I continued to build out the system. In the end, the company couldn’t commercially leverage what I built. There were several reasons. On the technical side, I had picked a series of technologies which their lead developers were not comfortable with and they decided to go with Java instead. That’s fine. I was a consultant and they were going to have to live with the technological choices for far longer than I would have.

Finally, I have worked on a couple projects where I had no energy beyond building the main task at hand. Sometimes this happens. The scope of the core project is so vast that there is no time or energy for off-process projects. Personally, I don’t find this as professionally rewarding, but it all depends on the case at hand. For short periods of time, it’s fine. However, the longer the 150% focus is, the more my brain starts pondering whether there isn’t a better way. In fact, quite often the tiredness brings on creativity and like a self-correcting system I begin to contemplate alternatives, new solutions, and, yes, side projects.

Like Robert Scoble says, these side projects aren’t Research efforts on par with those at PARC or Microsoft Research, however, as an engineer I find them quite valuable and rewarding.

As a developer, what’s particularly interesting about Gliffy is that it is built using OpenLaszlo, which as it’s site states is an:

…open source platform for creating zero-install web applications with the user interface capabilities of desktop client software. OpenLaszlo programs are written in XML and JavaScript and transparently compiled to Flash and soon DHTML. The OpenLaszlo APIs provide animation, layout, data binding, server communication, and declarative UI.

Think in terms of XAML or more appropriately WPF/e. An “app” starts with a <canvas> tag within which you can place text, buttons, images, animations, and so on. Here’s a simple program that displays “Hello World”:

<canvas>
<text>Hello World</text>
</canvas>

A “10-minute” programming tutorial will take you further into what OpenLaszlo can do.

For those of you familiar with WPF, you may want to check out OpenLaszlo’s use of the <class> and <method> tags and it’s ability to embed JavaScript in the XML. This shows a significant difference in philosophy between WPF/e and OpenLaszlo. OpenLaszlo is attempting to be a richer programming framework, not just a declaration of a UI. Yes, unfortunately, this means lots of XML angle brackets, but to me it’s captivating to see what can be done with this approach.

Currently OpenLaszlo generates Flash apps. When the platform can synthesize DHTML–as the site suggests it “soon” will–things could get very intresting. If the user-interaction can stay as rich as the current Flash apps, OpenLaszlo could become the web technology to watch for cross-platform, browser-based apps.

OK, you’re probably wondering when I’d ask myself how ink can fit into all of this. Here goes. Two things: First, OpenLaszlo is an open source project, so for those of us who like to push the envelope of ink adoption in the web, there might be an opportunity here to contribute. Second, I think ink will make more sense once the applications are compiled into DHTML. That way we don’t need to worry about trying to render variable pressure ink strokes in Flash. I imagine that this is something that needs to be natively. It would be nice if Flash could do it, but until then, I bet DHMTL and plug-ins that add ink to the browser are the way to go (such as this Firefox ink plug-in–REQUIRES FIREFOX 1.5).

I need to learn more about OpenLaszlo to see if this will be all that feasible. I don’t even know what OpenLaszlo is written in, nor if the source code is truly available, or if it’s easy enough to add something like an <<nkCanvas> tag to, and so on.