Matt O’ Rama

The Coefficient of User Innovation Friction

In February 2007, Mike Adams, who had recently joined Automattic, the company that makes WordPress, decided on a lark to endow all blogs running on WordPress.com with the ability to use LaTeX, the venerable mathematical typesetting language.

<snip>

Since then, as reported by observer/participant Michael Nielsen (1, 2), Tim Gowers, Terence Tao, and a bunch of their peers have been pioneering a massively collaborative approach to solving hard mathematical problems.

via Jon Udell, who is The Man

This story is cool in at least 2 ways. First, it warms the cockles of my hacker heart to hear that someone decided “on a lark” to add LaTeX to Wordpress. I never used LaTeX for anything only because I’m not a math person and I didn’t make it far enough in school to go beyond plain text. But deciding you’re going to add support for a beloved but extremely niche typesetting language to the blog software you work on is an impressive thing no matter what.

The main reason this story is cool is the collaborative project that emerged due to this niche feature. Sure, mathematicians could have, and I’m sure did, collaborate on sites before this but from what I read in the comments, adding formulas into websites previously was time-consuming at best. A long time ago there was talk about an addition to HTML called MathML to do just this but I’m not sure what happened to that, and in any case LaTeX is an accepted standard people are used to. So having support for this kind of thing is just the perfect reduction in friction that can help something new emerge. Having to learn a new standard or go through a whole process to display formula is enough trouble that most people won’t participate. If people can re-use existing skills in a new place, more people can contribute and do new things.

When Mike Adams added this feature, I’m sure he thought he helping a few mathematicians add formulas to their blogs and that was it. But the important thing was the removal of friction. If you can remove just a little friction from a social tool that a lot of people use, you’re opening it up to allow people to create new things you never thought of. When a new tool like Twitter or Google Wave comes out, I never pay much attention to the uses the creators come up with. What I really watch out for are the things the users come up with. It cost nothing for users to add hashtags to Twitter, but it’s incredibly useful and cool and will probably end up being part of how they make money. Whenever Google Wave comes out, the important things will be the ones people add later. If the friction is low enough.

Debugging By The Numbers

The other day my team had an all-day meeting to try to debug a very weird, ugly problem with some accounts in the new billing system we’re finishing up implementing. During the process of trying to figure out what the root cause of the problem was, I went through a process I’ve been through a few times and thought I’d share.

The issue was with how some money was distributed to the account. Sometimes people get money back and it has to be used in a specific way. In this case it appeared it wasn’t being spread out the way it should have, and the numbers looked very strange. In the main example case, we were using there was a number on the account’s invoice that didn’t match anything. When you’re debugging, these mysterious numbers can be very useful. While everyone else was looking at other stuff, I took a little while to try to find where that number was coming from. Code (hopefully) doesn’t just invent numbers so it had to come from somewhere and I’ve had good luck in the past figuring out big problems just by figuring out the numbers.

In this case, the important numbers on their invoice were

• A payment of $562
• A credit of $629
• A big refund of $2438
• A check issued to the account for $1348
• A credit balance of $562

First, we don’t usually do credit balances at all. It should have been $0. Then, $1348 didn’t immediately jump out as having any relation to the other numbers. Our non-technical project owner’s first inclination was to believe the program was making things up but I usually go on the assumption that this isn’t the case. :)

The first thing I figured out was that the $2438 had been split into 2 chunks of $1219 on 2 invoices. Since I didn’t know that this shouldn’t have happened (score another one for ignorance), I accepted it and figure out that $629 was $1219 – $562. So this was half the refund minus their payment, which is what should happen. Good.

I then saw that $1348 did have a relation to the other numbers, it was $629 * 2. I started going over this out loud for everybody (also an extremely valuable debugging technique) and it all fell into place. What I finally saw was that the $2438 had been split up over 2 invoices. Then both the month’s payments had been taken out of the refund -> $2438 – ($562 * 2) = $1348. The system had accounted for all the money the account would owe us, taken it out and refunded them the rest. It then held on the $562 for next month’s invoice in order to pay it off then. Whew. Only took about 2 hours.

So going over this math with a clear head and no expectation of what the system should have done, I found the underlying problem. Everything should have collapsed onto one invoice and done everything at once. The refund shouldn’t have been split up and both $562 payments should have been made at once, one of them shouldn’t have been held onto til next month. This is a big issue that makes people’s invoices look weird but the important thing for a billing system is that no money is missing. People had originally thought maybe we were over-paying accounts but that isn’t the case thankfully. Now we need to figure out how to fix it going forward but that’s a job for the billing people.

In the end, once again ignorance saves the day. I didn’t know about some of the particular workings of refunds in this case so I wasn’t making assumptions about that. I know I don’t know all the bits and pieces of how the invoices work so I went through the exercise of finding where the mysterious numbers came from and that led me to the answer. If you’re debugging numbers, writing it down and going through them all with a calculator is immensely helpful. Add them up, subtract them from each other, try to find where the differences are. And talk it out. Maybe you’re going down the wrong path or your lack of knowledge about something is something basic you do need to know. It’s debugging, it’s hard. There’s no map. But don’t let those mysterious numbers float out there, they might be the key to the answer.

Scope

Scope at reboot11, Matt Webb, S&W

This is a brilliant presentation about design and how it can affect us. Extremely worth reading.

The Psychology of Incompetence

YouTube – The Psychology of Incompetence – Ron Burk.

Very cool Ignite talk (5 minutes long) about incompetence in programmers and authority. I guess I’m okay because I have no illusions about my competence. :)

(via Ben Northrop)

TheBowlingGame Kata

Here is a kata for the Bowling Game problem. I have broken it down into the same tiny little steps that I do when I demonstrate it. However, as is usual for a kata, I have left out most of the explanatory comments.

A kata is meant to be memorized. Students of a kata study it as a form, not as a conclusion. It is not the conclusion of the kata that matters, it’s the steps that lead to the conclusion. If you want to lean to think the way I think, to design the way I design, then you must learn to react to minutia the way I react. Following this form will help you to do that. As you learn the form, and repeat it, and repeat it, you will condition your mind and body to respond the way I respond to the minute factors that lead to design decisions.

via TheBowlingGameKata by Uncle Bob

I’m going to go through this Bowling Game “kata” as soon as I can. There’s some very interesting stuff even just in the first few slides of the presentation.

I’ve seen a lot of these kata exercises and have always wanted to go through more of them in a more organized way; as in make a schedule to do a couple a week. This one though, is the first I’ve seen with enough detail that right away I can tell it’ll help a lot. More on my results / experience with this kata soon.

Project Coin Updates

Project Coin Announces Second Candidate List on InfoQ

At the JavaPosse Roundup a few months ago I got the chance to hear more about Project Coin, Sun’s “small change” additions to Java. I also got the chance to annoy the project’s leader, Joe Darcy, about the fact that BigDecimal math operators were off the table for Java 7. That still hurts but the latest updates to potential changes to be included in Java 7 takes quite a bit of the sting out. This is some cool stuff.

3. Indexing access syntax for Lists and Maps. Shams Mahmood Imam’s proposal aims to provide a consistent syntax for access elements of Arrays, Lists and Maps, so you could write:
myList[0] instead of myList.get(0) and
myMap["key"] instead of myMap.get("key")

I love this change. Much more readable and in line with how other languages do things. I’m always afraid when I say I like things because they’re more Perl-like that it will scare people away or they’ll change it just because of that but this does match my Perl biases from my former life so I like it. :)

4. Collection Literals. Intended to coexist with indexing access syntax for lists and maps and similar to a second proposal from Imam, Josh Bloch adds support for immutable list, set and map literals with a syntax similar to that of array initialisers. An example from the spec:
final Map platonicSolids = { 4 : "tetrahedron",
6 : "cube", 8 : "octahedron", 12 : "dodecahedron", 20 : "icosahedron"};

Same with this change, I like it a lot. Much less code for the same thing and it’s just as readable. Again, more like Perl without losing readability == good stuff.

Large arrays is a good change to give people flexibility, same with byte and short suffixes and using _ as a comma substitute in long numbers. Perfect “small change” inclusions.

It of course still depends on how much of this stuff gets in but just based on these lists of proposals, it seems like Project Coin will be a success. Everybody running the project and making proposals should be proud of themselves and be congratulated. Java 7 will be quite a bit nicer language because of their efforts.

Good old ignorance

I’m a big fan of ignorance. One of my favorite quotes goes something like “The one saying something is impossible shouldn’t interrupt the one doing it.” There have been a lot of times in my life where I was glad I didn’t know anything about the project I was doing beforehand because I wouldn’t have done it if I had. This is a very valuable way of looking at things, even though it can be hard to figure out when you actually do need to know something ahead of time so you don’t waste time or reinvent too many wheels. Every time I start a project I think about this balance but I haven’t figured out how to figure it out, if you get my meaning. In this post I want to talk about another benefit of ignorance, being willing to admit your own and how that can be a big help.

The other day at work we had our first design / planning meeting on a new piece of infrastructure. We’ve got enough different pieces needing to communicate that we’ve wanted to put a middle-layer in place for awhile now. Since we’re going to be starting our next big project soon, we all wanted to get this piece done before starting. In the meeting, my old friend ignorance played a big part. Specifically my personal ignorance.

The other 2 main Java programmers on the team and I were meeting with a programmer from our big vendor who also knows waaay more than I do about this middle-layer piece. It might have been annoying to my teammates but since I knew very little about how we were going to build this solution I kept questioning everything and having to have it explained to me. The reason I think this is a useful thing to do is twofold. One, we need to be able to explain this and justify it to everybody so having all of us understand is very valuable. I’m a pretty smart person overall so if I can’t catch onto something or see why we we would do something it’s a good bet others won’t either. The other reason is more important: explaining something to somebody who doesn’t get it forces you to think it through. If you take the first thing that comes to mind and just do it, you might end up with something more complicated than you really need or you most likely will have to redo parts of it later when you hit walls or are otherwise forced to think it through then. I don’t mind being the dumbest one in the room at all because of this. My personal preference goes along with the Agile/XP teaching of “Do the simplest thing that can possibly work” so I bring that along as well. After our meeting we came up with a really good design that builds on things we already have (reducing the amount of work needed), is easy to understand and justify, and will add real value to our system. It’s a testament to how well our team works together that we all contributed bits of work and knowledge and didn’t just rubber-stamp some design we all weren’t happy with.

Not being afraid to question things is a very helpful trait, even though some people might not like it. If you have questions about a design your capital-A “Architect” is proposing, do yourself and your team a favor and ask the question. Make people explain it. You have to be comfortable with the design of the things you build so if somebody else designs it, they need to make you comfortable. At the very least, that’s a courtesy to the team. At best, the design will get better as the designer has to think through answers to questions they might not have considered.

Thanks to the Dilbert Strip finder for helping me find this old favorite.

I’m Number 1(96)!

Top 200 Blogs for Developers (Q2 2009)

My former fellow co-author on AgileSoftwareDevelopment.com, Jurgen Appelo, periodically compiles a list of top blogs for developers. This time around, he did a Top 200 and I was surprised to see this very blog at #196! If you clicked over here from there, welcome! Since the list came out on the day I did my first post in a month (!), I’ve been self-shamed into posting more. :)

I’ve been working a bit with JavaFX so I’ll be posting about that and we just started on our next big project at work so I’ll probably be posting about that as well. On top of those topics I’ve made a list of important books I need to work through to help my Java programming so I’m planning on writing about that process. All in all, lots of geeky goodness to come I hope.

Responsibility

Since I think the word “architect” in a software context has taken on all sorts of horrible connotations (it conjures up images of people who draw boxes and arrows but don’t actually write any code themselves), I tend not to use it personally. Instead, I tend to think of my role on the team as being the guy who should be blamed when things don’t work. Not the guy who should be blamed when something he did doesn’t work, but just the guy to blame, period.

from Taking Responsibility by Alan Keefer on the Guidewire DevBlog

I was glad to see this article get some links from people like Kent Beck on twitter. I read it because Guidewire is a company I’ve worked with very closely (as one of our vendors at my job) for the past 2 years but I’m happy to see it getting read outside the circle of Guidewire customers. I’ve really admired what I know of the technical group at Guidewire and have angled numerous times for a job there. I’ve never met Alan and we don’t use the product he’s the architect on, but I liked this post a lot.

I’ve always thought the job of a manager is to take responsibility for their team, whatever that means. If somebody needs help, the manager needs to help. If there’s political corporatey nonsense going on, the manager is responsible for protecting their people from that. If something doesn’t get done, the manager should be the one taking responsibility for it with the higher-ups. Then if somebody on the team screwed up, it’s the manager’s responsibility to take care of it with that person. Managers that don’t take responsibility are not only not doing their job, they’re actively harmful to their team.

Of course, non-managers should be responsible to themselves and their team as well. I take care of my own stuff at work, but I also try to take care of things the team needs if they aren’t getting done. I’m not a manager but sometimes people just need to take over and get things done. We’re about to start a new project and we have some infrastructure projects that need to do. I could just wait for somebody else to do them or complain that we weren’t given time for them, but I got a whiteboard and started making a list, as well as scheduling a meeting with the parties involved to get a plan for putting these things together. I take that responsibility for my team because I know they would (and have) taken on things for me when I couldn’t. We’re all in this together and if any of us can take on things for the good of the team, we do.

Geek Humor

1936 – Alan Turing invents every programming language that will ever be but is shanghaied by British Intelligence to be 007 before he can patent them.

1936 – Alonzo Church also invents every language that will ever be but does it better. His lambda calculus is ignored because it is insufficiently C-like. This criticism occurs in spite of the fact that C has not yet been invented.

1940s – Various “computers” are “programmed” using direct wiring and switches. Engineers do this in order to avoid the tabs vs spaces debate.

from “A Brief, Incomplete, and Mostly Wrong History of Programming Languages”

hahahaha. Except for the part about Perl. :)