Michaeljon Miller : Randomness

Not surprising, but I have nothing to say

mikemill — Fri, 04 Jan 2008 21:49:00 GMT

It's not going to come as a surprise to anyone who used to read my blog and has noticed that it's been very quite. I realized that I really have nothing to say when I'm not working on a project that I can say nothing about. I have been working on a few interesting projects over the last two years, but neither one is something that I can publicly discuss. I've found that makes keeping my blog current particularly difficult.

I'll try to keep writing here as I move on to my next project - which is again extremely MSFT-only at this point. Hopefully I can find a way to talk about the different ways we're solving general problems in the space without giving away what it is there we're actually going to work on. How's that for promising and saying nothing.

Wow, just sitting here trying to explain why I have nothing to say is hard. I wonder what's happened that I'm gotten quiet. Weird...

WPC here I come

mikemill — Wed, 13 Jun 2007 19:48:00 GMT

I've finally registered for this year's WPC and I'm extending an invitation to MBS customers and partners to come chat with my team about some of our plans. We're currently putting together a short presentation to talk about what we're doing and how we think it impacts the MBS community. In return we're asking you to complete a short survey -- the plan is that is fits on a single piece of paper. If you're interested in participating, or just want to catch up, drop me a note and we'll set something up.

Poking my head out of the sand

mikemill — Fri, 17 Nov 2006 00:16:00 GMT

Wow, it's been a long time. I kept trying to come back and write something, but between working on new projects and trying to figure out what I could actually write about, well…

So, anyway, just to catch up. I left the CRM team at the beginning of the year to work in an incubation / greenhouse team within MBS. We were initially focused (well, "focused" might be too strong of a word) on hybrid application models. That is, we were looking at ways to create applications that spanned the firewall either directly or indirectly. One of our motivating factors was to introduce a collaboration element to MBS assets. We tossed around a handful of interesting scenarios, and in true Microsoft style, we went way overboard in developing the initial scenario (a building contractor doing collaborative bidding and design on home remodel projects).

One of the good things that came out of all that scenario work was a prototype for a "data projector" that could take internal line of business data and project it onto a shared, hosted workspace. I can't go into a ton of detail around this yet because the concept itself was useful enough that we're going to pursue it as a product. That means I need to be hush-hush about it until the official product team makes an announcement.

In the meantime I'm looking at the CRM platform through the eyes of an ISV (again) to see what we might be able to do with it in terms of building non-CRM products. Watch this space for more information as we learn things (like the callout implementation from CRM for notes and documents is just plain broken).

PS - Caitlyn is doing great, she sleeps through the night and has since we brought her home. Talk about a blast watching her learn about all the cool things in her new world.

Been very quiet around here

mikemill — Fri, 21 Jul 2006 03:32:43 GMT

It's been really quiet around here, well if we define "here" as this blog. It has been decidedly not quiet at home. As many of you know I finally graduated from Seattle University in the middle of June. I also packed up all the crap that was in my temporary apartment and moved it back into the house (which, by the way, still is not done 7 eight weeks after the scheduled completion date). That was on Friday the 23rd.

Turns out moving on a really hot day under a lot of stress can put a pregnant woman into labor. Go figure. So, on Sunday 6/25 my first child, a girl named Caitlyn, was born. I've had about 30 minutes to myself since then between dealing with the new baby, finishing the house, completing an incubation project, and teaching my other children (a cat and a dog) that the new baby isn't a threat, but an opportunity.

Thus, it's been very quiet around here. I'll be around the office until the first week of August or so and I'll try to take some time to respond to questions and write a little about what I'm working on. Anyway, it's off to the grocery store to pick up something that'll end up cold for dinner. Now I understand that line from A Christmas Story about the mother not having a hot meal in 10 years.

When software architecture isn't like building architecture

mikemill — Thu, 04 May 2006 23:27:00 GMT

We've all been through the talk about how building software is like building buildings. That somehow there's a correlation between creating a software model of reality and a physical model. I've even given presentations and taught course material that made comparisons between how we build buildings from the ground up with a plan and that we should do the same thing with software.

I'm sure we've all heard the flip-side of the same discussion which says that software architecture is somehow very different from building architecture because software is mutable. That is, if we get parts of it wrong today we can go back and fix it.

For the most part both of those arguments seem to hold. We want to build software with a plan and on a stable base. We build buildings that way and things turn out well. Right?

I noticed a difference last night when I received an invoice for "additions" which were made to my house. For those of you who don't know, I'm in the middle of a huge remodel project; this invoice was, I had assumed, my monthly "catch-up" payment against the original bid.

So, what's different between the two worlds. Well, in both software and buildings estimates can be incorrect. We don't always have all of the information we need so we make guesses. That's why we call the estimation process an estimate. It's not an exact science. At least it's not in the software world.

We've been building homes for many, many years now and we know a priori what's going to go into their construction. In fact, most building estimates are extremely close, which is why I was making monthly payments against the estimated cost and schedule. Well, I realized last night that it's entirely possible to have an immediate 20% cost overrun building a house (or remodeling one as it were). Why did this happen? Well, turns out that the architect hadn't done all the planning that typically goes into a house remodel plan -- he forgot three windows and ALL OF THE LIGHTS.

What's this got to do with software? Well, in software we learn things as we build the product. We do this because it's not possible to know everything about the product before we start building it. Cost overruns happen, and when there's doubt about the cost to build a feature developers even over-estimate to cover their asses and their customer's asses. Building architects never over-estimate. Ever. Not once. They always figure out everything they need to put into the project and everything "new" after that is a change order. They can get very good estimates this way and everybody comes out happy in the end. Unless the architect forgets ALL OF THE LIGHTS.

Inside MS-CRM goes Outside

mikemill — Tue, 07 Mar 2006 20:51:00 GMT

It all started with an email to a few guys working on a replacement lead management solution for MSN. The point of that email was that we could change the way software was built and create a new model for our partners around linking software to services in the clouds. Wow, now that I look back on it, that seems like a long time ago. Funny thing is that reading that email today brings back lots of memories of being very excited about being on the brink of something huge. When I read that email again last week while dusting off my office I realized that the excitement is still there. It's just shifted a bit for me.

The MS-CRM team has grown and changed over the last (nearly) seven years and I'm glad I was a part of it. I think the team set out to build something and after a few fits and starts actually outdid itself. We learned a lot on the way - both good and bad. I've grown and changed a lot over those same years. I've filled three roles on the CRM team: architect, developer, and overall pain in the butt. To any of those folks who dealt with me while I was on a rampage I apologize.

My decision to leave the team really didn't come as easily as a lot of people might think. There's a lot of cool work to be done on the product and I wanted to be part of that. However, I leave the product in very capable and caring hands. I trust them to do the right thing and I trust that they'll probably bounce their ideas off me on occasion just to see what the old guy says.

You know, it's kind of funny. I actually thought that MS-CRM would be the last team I'd work on at Microsoft. I really believe that the product has a future and I think the environment in which it sits today will start to adopt some of the principles that we put into the product. There were a few times where I figured this would be my last Microsoft job because I wasn't going to find anything else cool to work on. Yeah, I know, it sounds weird what with all the things that Microsoft does, but I couldn't find anything else I wanted to work on.

For the foreseeable future… or the next year, whichever comes first… I'm going to be working on hybrid line of business applications. One of the things I'd like to do is go back to the vision in that original email and see if we can tie all the goodness that is MS-CRM with a bunch more goodness in the clouds. So, I guess I'm going to start looking at MS-CRM as an ISV… from the Outside.

This is going to be pretty damned cool.

When did "Open Source" start to imply "Swiss Army Knife"?

mikemill — Tue, 28 Feb 2006 00:13:00 GMT

Todd Bishop mentioned the Higgins project this afternoon. For some reason this one just hit me wrong. I mean, we need a federated identity management system. Until we do everyone will have to roll their own solution and interop will just be a dream. But, just because Microsoft proposes something, does that mean that the open source community needs to come up with something different?

The quote that hit me was:

"Being an open source effort, Higgins will support any computer running Linux, Windows or any operating system, and will support any identity management system."

It's that repeated use of "any" that bothered me so much. It's as if it's going to solve all the world's problems. But, can it? Not really. Not out of the box. Instead, it's an "open" solution which I read as "download the bits, tweak them according to your needs, and hope for the best." Don't get me wrong, I think the OS community is doing great things. Sometimes though we just need a single-bladed pocket knife.

New-found respect

mikemill — Fri, 17 Feb 2006 00:37:00 GMT

I've been spending the last few weeks developing a graduate-level database modeling course as part of my MSE capstone project. Turns out that creating a 10 week long course covering database modeling as part of a Software Engineering program is a lot of work. It's not like the problem space isn't well understood. Quite the opposite: there's a ton of material available. I've done course development in the past, but it's usually limited to a single session, or at most a week-long "boot camp" style. This is completely different.

First, there's a fuzzy line between software engineering and computer science. This course is supposed to be firmly in the SE camp which means that deep dives into the theory of database systems is not part of the material. That's not to say that the information isn't interesting. It is. But, if you're a student trying to understand the SE aspects of databases so you can move up in the world (say from being a developer to being a project manager or senior designer) then you only need to know enough information about the implementation details to know when something is a seriously bad idea.

The course breaks down into two main sections: the first half, up to the mid-term, is the SE side of the theory. It covers topics such as locking, 2PL / 2PC, relationship types, normalization, and basic modeling techniques. The second half is all about well-understood patterns in the business application space. The second half is easy to justify - this information is immediately applicable to many student's current job. It's that first half that gets nasty.

Anyway, I used to sit in classes and think "I can do a better job teaching this class". I might still think that in some cases, but now I've had to put my money where my mouth is and prove that I can at least structure the class in the first place. I've always known that there's a huge skill and experience gap between the most and least experienced students. I had to keep that in mind the whole time and it changed the material that I could throw in. I compromised a bit though. Most of the material is aimed at the high-end of the average, but each module includes a set of additional reading to keep advanced students interested. I also threw an advanced topics module in during the last class week. It might be too deep for the less experienced students, but it should provide some head-scratching for the more experienced.

This class goes "production" for Spring quarter this year. I'll be attending as an observer to see how things pan out and I'll apply what I learn to tweaking that class and as input to two others that I'm working on. This should be interesting.

Why learn applied formal methods?

mikemill — Fri, 18 Nov 2005 07:58:00 GMT

I’m just about finished with the coursework portion for my MSE degree and figured my last quarter should have some fun classes instead of the “usual” ones. I’m taking a course called Applied Formal Methods. It’s all about writing specs using a formal notation, refining them until we get to a “program” and proving, along the way, that the program will be correct out of the box. There’s a ton of theory in this class, loads of unusual notation, not a small amount of math, and plenty of theorem proving.

So far we’ve been through basics proofs of if..then..else, while..loops, loop breaks, and for..loops. The question has come up several times in class and over a private email thread about how this course can a) be useful, b) be applied, and c) make it into the “real world”.

I've been thinking about this class for the last few weeks trying to come up with an answer to that question about how this stuff helps us design better programs. I think I've arrived at an answer only to realize that the answer was sitting right in front of me the whole time.

But first, a little background information to set the stage. Many of us took an Introduction to Programming or Principles of Programming Languages class some time as an undergraduate. There's a good chance that the tactics which you learned in that class never appeared to have any relevance to the rest of your undergrad work. [Insert any junior high student comment about how you’ll never use calculus or geometry in real life so there’s no reason to learn that either.] In fact, you might have thought at the time that none of what you were learning would ever be useful once you started designing or writing software.

Let's look at those topics for just a minute and see if they've be applicable to your career.

Abstraction building using procedures: expressions, the environment, scope, procedure application, black-box abstractions, recursion, growth and cost, procedures as data
Abstraction building using data: sequences, structures, sets, encoding, optimizations
Modularity, scope, state: variable scoping, assignment, volatile data, simulators, data structures, streams and infinite data structures
Abstraction: language evaluators, data as programs, programs as data, lambdas, closures, interpretation order, and programming models (logic, functional, imperative, declarative, applicative)
Machine architectures: register machines, routines, stack frames, allocators, garbage collection, tail recursion optimizations

So, given all that theory, what did we take away from it? The simple answer is that, although we might not feel we use these skills every day, we do use them. We use them without knowing that we use them, and they make us better designers and programmers. Learning that theory, even though we don't write a read-eval-print loop [see the Wizard Book if you don’t know what this is] every day, we know that it's the underlying technology on which interpreters, scripting languages, and debuggers are built. Although we don't implement red-black trees ourselves we know their performance characteristics and how they're implemented which allows us to make informed decisions about which data structures are best for a given application.

I did my undergraduate work long enough ago that we used LISP as the design and implementation language. I always wondered why I'd want to know LISP. Everything I'd seen up to that point had been BASIC, Pascal, C, Algol, COBOL, FORTRAN, or some other block-structured procedural language. I couldn't get my head around how LISP was going to help me write better C programs. Turns out I wasn't paying enough attention at the time and didn't realize that the concepts being taught are universal. They apply to every language, every program, every situation.

Formal methods are in the same boat. You may not directly apply the notations. You may not “prove” that a given algorithm meets a given requirement. You'll probably never find yourself doing formal refinement of a specification. But, you will start to think differently about how you write programs. You'll subtly change the way you think about requirements. You won't ask the customer to rewrite the requirements using CSP or Z or any of the other formal notations. But, when a customer asks you to implement a given requirement you'll stop for a minute and ask yourself if that requirement is strong enough to be implemented. Then you'll work with the customer to refine the specification until you both agree that it can be implemented, it can be tested, and it meets the customer's needs.

This isn't about learning a new technique for writing programs. It's about changing how your brain works when you start designing algorithms. Just like LISP teaches us how to rethink program constructs, formal methods teaches us how to rethink coding constructs. This is about adding two things to your toolbox: new tools and the skills to use them. (A few other useful tools are LISP-like languages, like Scheme, and functional languages like Haskell. I spent Winter break last year teaching my Haskell because I wanted to add something new to the toolbox.)

I'm waiting for the “formal methods” versions of the following papers. When that happens, formal methods will be the thing to learn. Again, not because we want to directly apply the “languages”, but because the concepts make us better.

Beating the Averages, Paul Graham, http://www.paulgraham.com/avg.html

How to Become a Hacker, Eric Raymond, http://www.catb.org/~esr/faqs/hacker-howto.html

One of those irritating technical things

mikemill — Fri, 21 Jan 2005 00:35:00 GMT

I was watching my local educational access channel this morning while walking on my treadmill. I thump pretty hard when I walk so I turned the TV up. That’s when I really started thinking about the volume control feedback. Why the hell does the volume go from 0 to 63? As a computer-savvy person I can sort of understand it, but come on now, 0 to 63? One of our televisions goes from 0 to 50. Ok, 50 is a ‘round’ number (at least to us who count using base-10). I don’t like 0 to 50 and would personally prefer 0 to 100 (still takes one byte of storage if that’s the problem) because then I might translate that to a percentage. But, ick. Is this worse than a stereo that goes to 11?

Web services aren’t distributed objects

mikemill — Wed, 01 Dec 2004 23:15:00 GMT

Why do we continue to try forcing a distributed object model into the world of web services? Nowhere in the name is there any hint that web service architecture has anything to do with distributed objects. Nowhere is there an implication that there are even objects involved in web service architecture. Sure, underneath the covers, in the private service implementation there are certain to be some kind of objects, if the service was written any time in the last decade or so.

But objects on the outside? Where did that notion ever come into play? Werner Vogel did a great piece [1] back in December 2003 that tried to dispel some of the myths that keep creeping in. I keep reading that article, and talking to developers around MBS, to see why web services keep getting lumped in with distributed object architectures. The only reason I can come up with is that the development community has had OO on the collective brain for quite a while and anything that looks like it might fit into the CORBA, DCOM, or RMI mold is dismissed as another distributed OO attempt. Web services will never take off until we start thinking in terms of services.

It’s really hard to do that though. Objects have all those nice characteristics that are pounded into our heads in school: data abstraction, information hiding, loose-coupling, separation of code from data… Wait a minute here. Aren’t those all things that web services provide too? Maybe that’s the reason we keep getting wrapped around the axle when we try to build new systems in a web services world. We want all that goodness, and the thing we’re taught to use is OO, so it must be the case that OO and web services are equivalent architectures. What can we do about it though?

Well, one of the key tenets of OO is that we should only ever deal with an object via its public interface. That means we shouldn’t worry about what’s inside the object, and we probably never should be shown what’s inside the object. That’s all good. What if we just change all occurrences of “object” in the preceding sentence with “service”? Close, but no cigar. Why? Because there’s a programming model difference between objects and services. When I create a solution using OO techniques I get to assume that I can create an object instance and hang on to it for as long as I want. I might even decide to pass it to another object instance for consumption. As the developer I probably get to hold on to precious resources, even though I don’t know that I’m doing it, because I get to control the object lifetime.

Hmm. That doesn’t sound right. What if one of those precious resources is a row in a table somewhere? (I know, it’s pretty hard to hold on to a row, but it’s not too hard to create a database transaction that holds a row.) Maybe the issue is that there are two levels of processing involved. Maybe the Smalltalk guys had the terminology right. Maybe what we send to an object is a message. That sounds right. Now, if we replace “object” with “service” we get to send messages to services. We don’t get to hold on to the “object” because it’s not there any more, it’s been replaced by a service.

Ok, so this is a lot of rambling. Is there a point? Sort of. The point is that we need to change the way we think about the programming model when we talk about building distributed systems using web services. We don’t get to control object lifetimes, we don’t get to hold on to precious resources, we don’t get to control transactions across multiple services. Instead, we get to ask a service to go do something for us and we let the infrastructure handle the how.

What’s the tie-in to CRM? Only that there are no distributed objects in the product. It’s all web services, and the “objects” are simply data structures that barely pass for documents. Why all that XML in the first two releases? Well, that was the technology available to us when we started and that technology solved the problem of getting programmers away from thinking that they needed to create objects and call methods.

[1] http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000343.html