On December 3, 2008, Logitech (my employer) announced that it had shipped its billionth mouse. While I didn’t contribute much to that as an employee (I work in a non-mouse division), I have helped as a consumer: I think I personally own four Logitech mice.

As part of the company internal celebration, there was a video contest with fairly liberal rules: One minute in length or less, something to do with mice.

Here is my prize-winning entry:

Friday was the third and final day of the QCon conference.

Frameworks and DDD (Tim McCarthy)

On Friday, I spent most of the day in the Domain Driven Design track, hosted by Eric Evans. The first speaker was Tim McCarthy, who has recently written a book on using DDD with.NET and C#. Tim raised an interesting question with his talk: How do you keep your domain code clean when working with frameworks? By frameworks, Tim meant broad frameworks like ASP.NET as well as more narrow, application frameworks like SharePoint. The challenge is that with frameworks, and especially the wizard/designer approaches to coding sometimes advocated by Microsoft, it can be really easy to become inappropriately coupled to persistence, specific APIs, etc.

Unfortunately, Tim had a couple of problems in his presentation that made it less valuable to me than it might have been. The first problem was being sort of backward in terms of audience (for me at least). He worried about whether people knew what SharePoint was, but breezed over DDD terminology. The second problem was getting bogged down in details of code from a real-world system. I’m sure that there were good ideas in there, but they were hard to see because of the context that needed to explained. There’s always something nice about real code for demonstrating a point, but in a presentation, maybe simple examples would be better.

Ultimately the point was that DDD provided strategies for a decoupled system. 

Rebuilding guardian.co.uk with DDD (Phil Wills)

I met Phil on Tuesday over lunch, so I was looking forward to hearing his presentation. It got off to a rocky start due to technical difficulties. The number of Macbooksat this conference really drove home the point that this wasn’t a Microsoft conference, but after a couple of failed attempts to get the presentation going with different Macs, Martin Fowler (whose machine was one of them) quipped that Macs being so superior is bullox.

Once the presentation got underway, Phil gave a little background about the Guardian. The newspaper has its roots in the 18th century, and is now the largest online newspaper in Europe. They put their first web site up in 1996, but over the years the system became problematic:

• Editors had to do a bunch of tedious manual work
• There were multiple URLs for the same resource
• New developers were hard to recruit because of the outdated technologies in use
• There was a lot of technical debt preventing big new features

To rebuild the site such that it would be “of the web, not just on the web” and ready for the future, they took an ambitious strategy of going agile, using new technologies and different design approaches (DDD). They got some help from ThoughtWorks to make it up the steep learning curve involved in such radical change.

Phil shared a few things they learned along the way. One thing was the importance of using the language of the problem domain everywhere, which allowed even the non-technical people on the team to contribute in unexpected ways. An example of this was a big breakthrough in terms of object composition. Phil showed an original object hierarchy and a much cleaner one. He said that of course, big breakthroughs always seem obvious and trivial in hindsight, but it was a non-engineer that came up with it. Another example he cited was a time when one of the users came over to a developer’s machine for a feature demo. While the develper was getting things set up, the user looked over his shoulder at the code and commented, “Does this do what I think it’s doing? If so, that’s not right.” Because the code used the domain language for object names and methods, he was able to understand it well enough to spot a bug.

Another thing Phil and his team learned is that the database schema is not the model. The model is the code — even though sometimes people get a false sense that if something isn’t in the database, it isn’t really the model.

He also talked about the utility of “value” objects. In Domain Driven Design, “entities” are the big stars, representing the main business objects. But it can be really valuable to have small, simple objects as helpers to the entities. These are objects that might just be represented as a string or an int, but if you discover some logic associated with that particular kind of string or int, encapsulating that logic into a slightly more specialized object can result in simpler entities.

Facebook Architecture (Aditya Agarwal)

I took a break from the DDD track to hear a little about the architecture of Facebook. Aditya is the director of engineering at Facebook, and after hearing his presentation, I came to a couple of conclusions:

1. I haven’t ever had to worry about scalability anywhere near this, and
2. I’m kind of glad about that.

Facebook is built on the LAMP stack, but pretty much every component has been customized and optimized for their particular application. They also use memcached, which Aditya said was a huge factor in the performance of the site. This agreed nicely with Tim Bray’s talk from the other day: databases are too slow for this kind of scalability. Aditya said their memcache distributed hash table consumes 25 terabytes of RAM.

When asked if they intend to submit their changes to LAMP components back into the main projects, Aditya said, “I don’t think they’d accept our hacks,” which got a chuckle from the audience. The slightly cynical part of me thought, that’d be an interesting way to keep from having to share GPL changes: saying, “Naw, you wouldn’t really want this hacked up stuff…”

Strategic Design (Eric Evans)

Back to the DDD track, to hear “Mr. Domain Driven Design” himself. His premise for this talk was:

Not all of a large system will be well-designed.

We wish it isn’t so, but it just seems to be a fact of life. He then talked about the oh so common situation that a development team finds itself in. We’ve got this legacy system, and it has all the problems that typically make us unhappy with legacy systems: poor design, old technologies, accidental complexity, etc. So what do we do?

Plan A: Scrap it and start over. Eric had a diagram showing the big ball of mud becoming this beautiful pyramid of a system. What ends up really happening? Everything seems fabulous at first as a solid base gets built up. Then, at the point where parity with the legacy system is supposed to appear, panic sets in. The is the classic case documented by Joel Spolsky where you suddenly realize that all that seemingly pointless cruft was actually important. So you finally end up with a system, two years later, that does exactly what the original system did, and that final phase of “add cool new features” never seems to happen.

Plan B: Refactor. Eric argued that this approach doesn’t really work either. There aren’t enough tests to really work something over, and while you’re trying, other people are continuing to hack the code base and mess up your perfect plans. He joked that the hackers are irresistibly drawn to the code that you just cleaned up.

Plan C: Plan to hack, since that seems like what will happen anyway.

Leaving behind the plans for a while, Eric talked about the different parts of the domain. He said that this is covered in chapter 15 of his book, but I’ll try to summarize as I understood it from the talk.

The biggest part is the generic subdomain. This is all the framework and code that is pretty generic and applicable across the whole software development practise. Next is the supporting subdomain, which is code that starts to be more specific to the problem domain you’re working in, but could still be applied somewhat generically in a specific industry. Finally, the smallest bit, is the core domain. This is what makes your system worth building in the first place. This is what gives you your competitive advantage. This is why people will buy your stuff. Another perspective of the three levels is stuff you buy, stuff you outsource, and stuff you build, respectively.

Next, a question: Why do irresponsible programmers become heroes? It’s largely due to mistakes that responsible programmers make. What do responsible programmers do? They build frameworks because they don’t trust that the hackers can build something without some kind of scaffolding. They go around cleaning up other people’s messes. As a result of these, they don’t produce the sexy new features, and shield the hackers from the consequences of their poor practices. The key, though, is that the heroes are working in the core domain.

Plan D: Distill the core domain from the ball of mud. Instead of considering the legacy system a liability, look for the assets. Build what Eric calls an Anti-Corruption Layer, which sounded kind of like the façade pattern to me. Instead of transforming the ball of mud into a beautiful pyramid, focus on building the very cap of the pyramid (the core domain) and making that beautiful, while connecting to the ball of mud as necessary, but with a clear insulating layer.

This topic is really intriguing to me, but I can’t say that I understand how to apply it. Eric remarked that all of this stuff is in his book, but being toward the end, some people don’t, uh, quite make it that far. Guilty as charged. Well, although I’ve got the book, I haven’t really made a serious effort to read it yet. Maybe it’s time to fix that.
 

Publishing and Protecting the Model (David Laribee)

Since Eric Evans’ talk was so good, I thought I’d finish out the day with the last talk in the DDD track. This was by David Laribee, who is billed as the ALT.NET ring leader. ALT.NET is a community that I’ll unfairly and over simply summarize as “I can write C# on a Mac”.

Dave’s talk was about keeping the model clean, given that it has to be exposed to the unwashed masses to be useful. Or something like that. Maybe after three full days of presentations I was just full, or maybe Dave wanted a cool presentation more than a pragmatic one, but I had a hard time following this one. It started out at a high philosophical level, and by philosophical I mean classically so: Plato and Aristotle. It ended with C# 3.0 extension methods. I’m sure I’m not doing it justice.

It’s another day of industry stand-outs at QCon.

Shifting Storage (Tim Bray)

The day started with a keynote from Tim Bray, of XML fame. Tim spoke about the application stack from this perspective:

• Application code
• Object-relational mapping
• SQL engine
• Operating system/file system
• Cache/disks

He mainly focused on the O/R mapping layer and the SQL engine, where technology, to quote Tim, “sucks”. O/R mapping is really hard, and it’s too bad that object databases never really got commercial success (Martin Fowler in the front row nods in agreement). SQL engines are too slow, driving people to distributed hash tables like memcached instead, or even skipping the database engine entirely to go to the file system. SQL engines are also complex and laden with features that never get used. This is inspiring projects like Drizzle, a database forked from MySQL in an attempt to slim things down.

Tim also had good things to say about CouchDB, a document-oriented database that is accessible only via HTTP. I don’t know anything about this project, but Tim’s exact words were, “I’m infatuated with this” and “frighteningly elegant”.

Another topic was comparing the relative speeds of the storage stack, from CPU registers down to hard drives. The interesting technology coming into this area is solid state drives. His benchmarks show that write speeds are about that of a middling hard drive, but read speeds are really, really good.

Given that most web applications are I/O limited, it can really pay off to keep your eyes on up and coming technologies like alternate data strategies and solid state drives.

HTTP Status Report (Mark Nottingham)

I went over to the REST track for a little bit, chaired by Jim Webber, a noted expert on man boobs. The speaker for this session, though, was Mark Nottingham, the chair of the HTTPbis working group. They are essentially rewriting the HTTP 1.1 spec, but not trying to add any new features. Why bother? Mark explained that the existing spec is ambiguous, not well organized, not very approachable, and occasionally requires consultation with one of the authors to understand. As a result, everybody pretty much gets the main parts right, but there are a bunch of other things that are not very interoperable between implementations. HTTPbis, targeted for completion in about six months, will hopefully clarify the spec enough to eliminate incompatibilities.

Mark also spoke briefly about what might be expected for the future of HTTP, like a standard set of conformance tests, better authentication, transport over SCTP instead of TCP, and others.

Joys and Pains of Long-Lived Code (Jeremy Miller)

I had just read Jeremy’s Cohesion and Coupling article in MSDN last week, so it was nice to put a name to the face. Jeremy gave a retrospective of StructureMap, an IoC container he has been writing and maintaining over the past five years. He talked about the changes that have happened over the life of the project, both in the .NET community and the .NET platform itself, and how things he had done with StructureMap made adapting to those changes easy or hard.

These are some of the lessons he learned.

• Good design at the class level is crucial.
• Bad tests make it harder to change the code rather than easier.
• TDD as refined to BDD is best (I need to learn more about this).
• Getting abstractions right not only improves the code, it opens up new possibilities.
• DRY - even a little duplication is bad.

I also appreciated a comment he made when answering a question: don’t use an IoC container when writing tests. I’ve seen people do that in the past: they have a constructor injected set of dependencies and try to reconfigure the container to inject mocks. Just pass the mocks in the constructor!

F# (Don Syme)

While I have heard a bit about F#, I’ve not really spent much time trying to understand it. What better opportunity could you have than to get the designer to provide an introduction? Of course learning a language is best done by writing code, not hearing a presentation. Still it was interesting to get a high-level overview and to see a few examples. One of Don’s favorite things was to show the difference in lines of code between functionally equivalent bits of C# and F#. An asynchronous I/O example had three pages of C# code to a dozen lines of F#.

Don said that F# is well-suited to problems dealing with data transformation, but not so great for building user interfaces (even though all the .NET UI libraries are accessible from F#).

TDD and DbC (Greg Young)

I’ve posted about design by contract in the past (part 1, part 2), and sort of intended to talk about unit testing and DbC at some point, but never got around to it. So I was interested to hear what Greg had to say. The first part of his talk was an overview of DbC, showing some spec# code to demonstrate the concepts and letting the code verifier find the problems. I noticed that Microsoft had announced a contracts library at PDC, so the exploratory work of spec# will be incorporated into the framework instead of as language extensions.

The main point of Greg’s presentation is that tests and contracts are complimentary. Tests should focus on the behavior (another reference to BDD) while contracts focus on constraints. Having contracts means fewer tests to write because you don’t have to write all the dumb tests that check that an argument exception is thrown when parameter x is null. In fact, not only do you not need to write those tests, if you try anyway the code verifier will complain. So you almost can’t write those tests, and therefore contracts push you toward testing the meaningful behavior of the code.

Democratizing the Cloud - MS Volta (Erik Meijer)

I’m again impressed with the caliber of speakers here. Eric Meijer is the guy who designed LINQ, among other things. Currently he is working on Volta, which put bluntly, is GWT for .NET. Volta allows translation of MSIL to Javascript so that you can build client apps writing .NET code. If you happen to have Silverlight on the client, you can also target that as the runtime environment instead of going to Javascript.

There is also a development work flow in which you write a single tiered .NET application, then split it into client and server tiers by simply annotating the code — saying which bits should execute on the server and which on the client. Greg Young, from the previous presentation, immediately started pushing back citing the 8 fallacies of distributed computing. Erik simply skipped ahead a little to a slide showing the 8 fallacies, and assured the audience that programmers would still be in control enough to avoid the pain.

Erik’s description of the translation of IL to Javascript was interesting. They are not making any attempt to produce Javascript that follows typical Javascript style. Instead they use it like an assembly language, and focus on preserving the precise semantics of the .NET code. This gets a little tricky in some cases, such as jumps. Javascript has no goto, but IL, being very low-level, uses them extensively. Erik showed how they used switch statements to get the same behavior. It’s not pretty Javascript, but that’s not really the point.

The presentation went down a little bit of a rat-hole when Erik talked about some security issues. There was quite a bit of debate from some folks the audience about whether they were doing it right. While it’s neat to see that kind of interaction, I’m not sure it is a good use of time for people seeing this for the first time to try to give informed design criticism.

Volta is still a work-in-progress. It will be interesting to see if it can mature into something that will give as great a development experience as Alex Moffat described yesterday with GWT.

QCon is a software development conference sponsored by the InfoQ site and software consultancy Trifork. Here I am in San Francisco attending it, and here is a summary and some thoughts on the first day’s sessions I was able to attend.

Agilists and Architects (Martin Fowler & Rebecca Parsons)

As much of Martin Fowler’s stuff as I’ve read, I hadn’t ever heard him speak in person. He and Rebecca talked about software architects, including some of the stereotypical ivory tower thinkers that come up with beautiful, elegant systems that have no possibility of actually working in the real world. A video clip from The Matrix Reloaded set the tone: the architect of the matrix considers Neo to be an aberration in his otherwise mathematically perfect construct.

Part of the problem with architecture is that it is hard to define. It may be simply design when we want to make it sound more important. I remember a guy I used to work with for whom everything was architecture. “If you think about the architecture of these two classes…” Martin liked Ralph Johnson’s definition of an architect as the person who thinks about the hard stuff — whatever that happens to be for a particular organization.

Another problem is that architects have a hard time defining success for their role, and an even harder time attaining it. Sometimes that’s because of organizational dysfunction, like companies that insist that architects not write any code. Other times it is through poor practices, like inventing frameworks in anticipation of a yet unproven need.

The speakers emphasized, however, that architecture has a useful role in spite of some of the difficulties with having it filled effectively. The architect is the one who worries about supportability, rampant proliferation of tools, and keeps in mind the grand vision of the product. They are also responsible for the quality of the code, which is not just an abstract, academic thing once the code works. The quality of the code has a real cost that is realized when new features need to be added. It can be hard to make that cost visible to people, but one approach suggested might be to give two estimates: one for the new feature built into the mess we’ve currently got and one for the imaginary clean system we wish we had. I don’t know, that still sounds kind of hard.

Web as Platform (John Musser)

John is the founder of Programmableweb.com, a sort of catalog site for various APIs available over the Internet. In his presentation, he talked about trends in web APIs. Some trends are technical such as the rising use of REST vs. SOAP (though since REST is more a philosophy than a standard, it can be hard to classify something as REST as opposed to REST-ish). Other trends are around the ubiquity of APIs — it is now expected that if you put useful functionality on the web that it will have an API, and not just a user interface. Even media producers like The New York Times and NPRhave APIs.

What makes a good web API? First and foremost, the underlying service has to be valuable. Beyond that, the API should support the business model of the provider (eBay wants to optimize adding listings since that’s how they make money) and should be easy to access both in terms of openness and the developer support provided.

Hard Rock: Silverlight 2 (Scott Stanfield)

Scott is the CEO of Vertigo, a consulting firm that was named Microsoft partner of the year for 2008. It was nice to have some Microsoft technical representation since the conference so far seems heavier on the Java side. Scott spoke about building the Hard Rock Memorabiliasite working with marketing firm Duncan/Channon. Duncan/Channon originally intended that the site be done using Flash, but Deep Zoom turned out to be the killer feature that made Silverlight the clear choice.

Scott said that the Silverlight story of independent graphic design and programming is completely playing out as advertised. He showed a little demo of an Etch-A-Sketch app that Vertigo programmer Michael Moser quickly coded up, but was then beautifully skinned by a graphic artist.

Scott also asserted that the adaptive streaming of video in Silverlight gives the best video on the web.

One interesting tidbit on the Hard Rock site is that Vertigo spent some significant effort getting a set of different sized pictures to line up in such a way that the final arrangement creates a nice rectangle. This looks like possibly a variation of the packing problem to me.

Also interesting was that Scott was using a Mac with Vista running in a VM. Come to think of it, all the presenters in the RIA track seemed to have Macs.

Flex and AIR in the Trenches (Scott Delap)

Scott Delap gave a presentation about using Adobe tools to build some online components of a video game, League of Legends. His perspective was comparing Flash/Flex to doing Java UI development with Swing. He seemed reasonably happy with the platform and development tools, but thought that things felt sort of like Java year 2000. That is, not quite up to state-of-the art. He is, however, a convert to declarative UI specification. Like the Java UI developers I’ve known, he never really trusted visual designers for Swing, but says the designer experience with Flash is great.

Scott talked about evaluating a lot of frameworks for various things (dependency injection, remoting, unit testing, functional testing, etc.) which is a typical exercise for open source development stacks.

10 Ways to Improve Your Code (Neal Ford)

This talk covers some of the same material that is in Neal’s book The Productive Programmer. I sort of got the impression that maybe after writing a book and giving this presentation who knows how many times that Neal might have lost some of the passion associated with this topic. That’s not to say that the presentation was dull, it just seemed a little like, “OK, here we go again…”

Neal’s 10 points were mostly things I know (and even dosuccessfully at times) such as TDD, using static analysis, YAGNI, etc. There was an interesting point on polyglot programming. He said that polyglot programming ideally doesn’t mean multiple platforms, but multiple languages on a single platform. Java and .NET are both multilingual platforms, so take advantage of that to use the best language for the problem at hand while still keeping the benefits of a common runtime environment.

As an intermission, Neal talked about 10 bad smells, my favorite of which was “Our lawyers say we can’t use any open source software”, which led to Neal having to buy a “license” for CruiseControl (written by Neal’s employer, ThoughtWorks) so he could use it with a client.

Real World GWT (Alex Moffat)

In short, Alex and his team love GWT. And I have to say that seeing Blueprintin action was pretty spectacular. It really looked like a desktop application, but done entirely with HTML and Javascript. GWT is the magic behind it all, which is Google’s toolkit for compiling Java to Javascript.

If you work in a Java shop, it seems like a great development story: use all your familiar tools and write Java code and you get a great web app.

Just You Wait (Kent Beck)

Kent Beck, like Martin Fowler, is another industry heavyweight that I first heard speak today. He got started a little late because his talk came right after the break in which beer was served, and I guess it’s hard to compete with that. Being a non-drinker, I had a seat right up front.

His talk was as an amateur futurist, looking at trends and imagining where they might go. For example, what happens if you extend the trend of releasing software more frequently? Maybe releasing software with every keystroke? Well, OK, editing a live web site would almost be that (if your editor saved continuously).

Some other trends he expects are the end of “free” stuff on the web, and a decrease in status for programmers as other people begin to understand technology more and programming seems less mystical. Even if that latter point proves true, he says that we can still make a difference in the world with what we build, and how we build it.

[Due to some connectivity issues, I'll have to add pictures later...]

QCon is a software development conference sponsored by the InfoQ site and software consultancy Trifork. I am in San Francisco attending it, and here is a summary and some thoughts on the first day’s sessions I was able to attend.

Agilists and Architects (Martin Fowler & Rebecca Parsons)

As much of Martin Fowler’s stuff as I’ve read, I hadn’t ever heard him speak in person. He and Rebecca talked about software architects, including some of the stereotypical ivory tower thinkers that come up with beautiful, elegant systems that have no possibility of actually working in the real world. A video clip from The Matrix Reloaded set the tone: the architect of the matrix considers Neo to be an aberration in his otherwise mathematically perfect construct.

Part of the problem with architecture is that it is hard to define. It may be simply design when we want to make it sound more important. I remember a guy I used to work with for whom everything was architecture. “If you think about the architecture of these two classes…” Martin liked Ralph Johnson’s definition of an architect as the person who thinks about the hard stuff — whatever that happens to be for a particular organization.

Another problem is that architects have a hard time defining success for their role, and an even harder time attaining it. Sometimes that’s because of organizational dysfunction, like companies that insist that architects not write any code. Other times it is through poor practices, like inventing frameworks in anticipation of a yet unproven need.

The speakers emphasized, however, that architecture has a useful role in spite of some of the difficulties with having it filled effectively. The architect is the one who worries about supportability, rampant proliferation of tools, and keeps in mind the grand vision of the product. They are also responsible for the quality of the code, which is not just an abstract, academic thing once the code works. The quality of the code has a real cost that is realized when new features need to be added. It can be hard to make that cost visible to people, but one approach suggested might be to give two estimates: one for the new feature built into the mess we’ve currently got and one for the imaginary clean system we wish we had. I don’t know, that still sounds kind of hard.

Web as Platform (John Musser)

John is the founder of Programmableweb.com, a sort of catalog site for various APIs available over the Internet. In his presentation, he talked about trends in web APIs. Some trends are technical such as the rising use of REST vs. SOAP (though since REST is more a philosophy than a standard, it can be hard to classify something as REST as opposed to REST-ish). Other trends are around the ubiquity of APIs — it is now expected that if you put useful functionality on the web that it will have an API, and not just a user interface. Even media producers like The New York Times and NPR have APIs.

What makes a good web API? First and foremost, the underlying service has to be valuable. Beyond that, the API should support the business model of the provider (eBay wants to optimize adding listings since that’s how they make money) and should be easy to access both in terms of openness and the developer support provided.

Hard Rock: Silverlight 2 (Scott Stanfield)

Scott is the CEO of Vertigo, a consulting firm that was named Microsoft partner of the year for 2008. It was nice to have some Microsoft technical representation since the conference so far seems heavier on the Java side. Scott spoke about building the Hard Rock Memorabilia site working with marketing firm Duncan/Channon. Duncan/Channon originally intended that the site be done using Flash, but Deep Zoom turned out to be the killer feature that made Silverlight the clear choice.

Scott said that the Silverlight story of independent graphic design and programming is completely playing out as advertised. He showed a little demo of an Etch-A-Sketch app that Vertigo programmer Michael Moser quickly coded up, but was then beautifully skinned by a graphic artist.

Scott also asserted that the adaptive streaming of video in Silverlight gives the best video on the web.

One interesting tidbit on the Hard Rock site is that Vertigo spent some significant effort getting a set of different sized pictures to line up in such a way that the final arrangement creates a nice rectangle. This looks like possibly a variation of the packing problem to me.

Also interesting was that Scott was using a Mac with Vista running in a VM. Come to think of it, all the presenters in the RIA track seemed to have Macs.

Flex and AIR in the Trenches (Scott Delap)

Scott Delap gave a presentation about using Adobe tools to build some online components of a video game, League of Legends. His perspective was comparing Flash/Flex to doing Java UI development with Swing. He seemed reasonably happy with the platform and development tools, but thought that things felt sort of like Java year 2000. That is, not quite up to state-of-the art. He is, however, a convert to declarative UI specification. Like the Java UI developers I’ve known, he never really trusted visual designers for Swing, but says the designer experience with Flash is great.

Scott talked about evaluating a lot of frameworks for various things (dependency injection, remoting, unit testing, functional testing, etc.) which is a typical exercise for open source development stacks.

10 Ways to Improve Your Code (Neal Ford)

This talk covers some of the same material that is in Neal’s book The Productive Programmer. I sort of got the impression that maybe after writing a book and giving this presentation who knows how many times that Neal might have lost some of the passion associated with this topic. That’s not to say that the presentation was dull, it just seemed a little like, “OK, here we go again…”

Neal’s 10 points were mostly things I know (and even do successfully at times) such as TDD, using static analysis, YAGNI, etc. There was an interesting point on polyglot programming. He said that polyglot programming ideally doesn’t mean multiple platforms, but multiple languages on a single platform. Java and .NET are both multilingual platforms, so take advantage of that to use the best language for the problem at hand while still keeping the benefits of a common runtime environment.

As an intermission, Neal talked about 10 bad smells, my favorite of which was “Our lawyers say we can’t use any open source software”, which led to Neal having to buy a “license” for CruiseControl (written by Neal’s employer, ThoughtWorks) so he could use it with a client.

Real World GWT (Alex Moffat)

In short, Alex and his team love GWT. And I have to say that seeing Blueprint in action was pretty spectacular. It really looked like a desktop application, but done entirely with HTML and Javascript. GWT is the magic behind it all, which is Google’s toolkit for compiling Java to Javascript.

If you work in a Java shop, it seems like a great development story: use all your familiar tools and write Java code and you get a great web app.

Just You Wait (Kent Beck)

Kent Beck, like Martin Fowler, is another industry heavyweight that I first heard speak today. He got started a little late because his talk came right after the break in which beer was served, and I guess it’s hard to compete with that. Being a non-drinker, I had a seat right up front.

His talk was as an amateur futurist, looking at trends and imagining where they might go, and unintended consequnces. For example, what happens if you extend the trend of releasing software more frequently? Maybe releasing software with every keystroke? Well, OK, editing a live web site would almost be that (if your editor saved continuously).

Some other trends he expects are the end of “free” stuff on the web, and a decrease in status for programmers as other people begin to understand technology more and programming seems less mystical. Even if that latter point proves true, he says that we can still make a difference in the world with what we build, and how we build it.

Thinking of the Brazilians that were recognized in attendance, I flinched a little during the talk when Kent digressed slightly about how his son says “cool”, but to be really cool leaves off the ‘L’. There’s another unintended consequence for you, riffing on a word that is vulgar in Portuguese.

The current stock market makes the title generally appropriate, but I’m specifically talking about Microsoft Money here. I used to use Quicken pretty heavily, but I got tired of forced upgrades so I’ve been using Microsoft Money for a little while. Now I’m happy to be done with both of them.

The thing that appealed to me about Microsoft Money Plus is the “Essential” user interfaces. They’re simple, clean ways of doing basic personal finance geared toward people who get their transactions electronically and aren’t accounting hobbyists.

Unfortunately, the Essential features are on or off — there’s no way to just dip a toe into “advanced” features. If you venture into such financial rocket-science as splitting a transaction across categories or adding a memo to a transaction, you have to surrender the streamlined UI and switch completely to the Advanced Register. Some Essential features are just broken, like credit card payments not counting as expenses in reports (since the credit card transactions already account for those expenses). The documentation explains it exactly how it should work, but apparently someone forgot to tell the developers. So while the Essential UI showed promise, it was ultimately just disappointing.

After some guilty months of ignoring my finances, I thought, “Heck, I’m a software engineer. I’ll just write my own application.” How hard could it be? With a database and a grid control I’d be halfway there. Of course, there’s the critical part about downloading transactions… There’s probably some standard protocols for that somewhere. Then I noticed line at the bottom of the account register in Money:

Account information provided by Yodlee, Inc. or your financial institution’s online services.

What’s Yodlee?

A quick Google search led me Yodlee and Mint.com, both online applications for personal finance. The consensus seemed to be:

• Yodlee: More powerful
• Mint.com: Built on Yodlee services, better UI

I went straight for Mint.com.

These are the things that I’ve come to like about Mint.com:

• It does have a pretty nice, AJAX UI.
• I was able to connect it to all my financial institutions, including things like PayPal, my mortgage and 529 savings accounts, which I could never figure out with MS Money.
• Since the application is running on a server, it knows what’s going on without me having to download transactions (or even boot my home machine), and can send me alerts about potentially interesting things like large transactions, budget overruns, etc.
• It sends a nice financial summary each week to both me and my wife.
• It’s free.

What about concerns?

Security is a pretty important consideration, but they seem to have done a reasonable job being at least as secure as your bank.

Their business model is around making sponsored recommendations based on your financial situation. For example, if you’ve got a high-interest credit card, they’ll recommend a lower interest alternative. Hopefully that model is sustainable.

There are still some bugs in the system. One of my accounts won’t update (I’ve got an open ticket on that one), and my budget disappeared for a little while.

Despite these, I’m cautiously optimistic that I’ve found a superior alternative to Quicken and Money.

The “story” in agile development’s “user story” is not a narrative in the traditional sense of the word. Many are short on verbs, which is a big hint that something non-narrative is going on. “User story” is shorthand for a set of concepts and principles. The danger with taking a simple word like “story” and assigning it a new meaning is that novices, and occasionally even experts, confuse the jargon with the traditional definition.

An example of an expert forgetting the jargon of “user story” is in a small section of Mike Cohn’s otherwise great book User Stories Applied. Here, the author is talking about the benefits of user stories over other ways of specifying requirements:

Additionally, a study in the late 1970s found that people are better able to remember events if they are organized into stories (Bower, Black and Turner 1979). Even better, study participants had better recall of both stated actions as well as inferred actions. That is, not only do stories facilitate recall of stated actions, they facilitate recall of the unstated actions. The stories we write can be more terse than traditional requirement specifications or even use cases, and because they are written and discussed as stories, recall will be greater. 

While I haven’t read the study mentioned (maybe this is the abstract?) I doubt they were studying agile “user stories” back in 1979. From what I’ve been able to gather from secondary sources, they were studying how stories (in the narrative sense) have a more abstract representation than the actual words that are said, and that memory relies more on that abstract representation such that it’s hard to remember if something was explicitly said in the story or just implied.

In short, applying the results of this study to user stories is pretty bogus.