+972 52-548-6969
Reducing friction as a standard operating method
One of the things that I am really sensitive for is friction. And anytime that I run into that, I am doing an evaluation about how much it is going to cost to remove that. Thee are two sides for this evaluation. There is the pure monetary/time side, and then there is the pure opportunities lost side.
The usual evaluation is “it takes 3 minutes to do so manually, and would take a week to resolve in an automatic way”, assuming a standard 40 hours week, we would need to do something for 800 times before it make sense resolve that automatically.
The problem is ignoring the opportunities lost angle. One of the things that most people do not usually consider is that we tend to avoid things that are painful.
If adding content to a website requires you to commit changes to SVN and then log in to a server and update the site, that is about 3 additional minutes that you topped to something that is probably pretty minor. If you are on a slow connection, those can be pretty frustrating 3 minutes. That means that editing the site get batched, so a lot of minor edits are bundled together, until the 3 minutes overhead become insignificant. That means that the site gets updated less often.
If maintaining two profiles of the same application requires that you would merge between slightly different branches (a pretty painful process), they are not going to be in sync. Building a way which allows a single codebase development for multiple profiles is a pretty significant investment, on the other hand. And it introduce complexity into the software.
If committing is going to hit a network resource (and thus take a bit longer), you are going to commit less often. If branching… but you get the point, don’t you?
If releasing your software is a manual process (even to the point of just promoting a CI build to release status), you aren’t going to release very often.
Those are just a few recent examples that I have run to where friction was the deciding factor. In all cases, I put in the time to reduce the friction to the lowest possible level. What I usually look for is the opportunities lost cost, because those tend to be pretty significant.
I don’t think about releasing the profiler versions, and I released 20 times in the last three days (5 different builds, times 4 different profiles). The build process for the profiler had me write several custom tools (including my own bloody CI server, for crying out load, a daily build site, upload and registration tools, etc). That decision has justified itself a hundred times over, by ensuring that my work isn’t being hampered by release management, and it a very rapid turn around for releases.
That, in turn, means that we get a lot more confidence from customers (we had a problem and it was resolved in 2 hours). There is actually a separate problem here, that we release too often, but I consider that a better alternative than slow response times for customers.
Supporting Linq to Sql as a second target in NH Prof was something that we could do in three days flat. In practice, it took over a month to get to a position where we could properly release it. The time difference was dedicated to doing it right. And no, I am not talking about architectural beauty, or any such thing.
The three days target time for Linq to SQL implies branching the code base and simply making the changes inline. There is relatively very little change from the NH Prof version, and we could just make it all work in a short amount of time.
I am talking about doing it in a way that introduce no additional friction to our work. Right now I am supporting 4 different profiles (NHibernate, Hibernate, Linq to SQL, Entity Framework), and in my wild dreams I am thinking of having 10 or more(!). Frictionless processes means that the additional cost of support each new profile is vastly reduced.
Having different branches for different profiles was considered and almost immediately rejected, it would introduce too much friction, confusion and pain into the development process. Instead, we went with the route on having a single code base that is being branched automatically by the build process. It means that we have a slightly more complex infrastructure, but it also means that we can do it once and touch it only very rarely.
Does it pay off? I would say it does just in terms of not having to consider merging between the different branches whenever I make a change or a bug fix. But it is more than that.
A week ago I didn’t have the Entity Framework Profiler, today it is in a private beta, and in a week or two it is going to go to public beta. All that time spent on integrating Linq to SQL paid itself off when we could just plug in a new profile without really thinking about it.
Comments
"single code base that is being branched automatically by the build process" <-- huh? Can you elaborate on that? Sounds interesting
Also I think that by reducing friction your are actually making the task of developing software more fun. If you like your work you get more done. At least I think so :)
Very nice commentary about friction. Although necessary, it's unfortunate that programmers have to work alongside business people who want results immediately because that's the biggest driver of how things are eventually done. This often times prevents the developer from doing it right the first time and causing the developer much friction along the way.
@Brian
I think friction is introduced by limitations of your tools or your knowledge/abilities, not by customers themselves. If business people want results NOW there's nothing to discuss - either deliver it NOW or persuade the customer to change requirements. You cannot call customer requirements a 'friction' because usually the more difficult the requirements the more money you will get for satisfying them - friction is everything that makes the task more difficult than it is 'by definition'.
I am an advocate of things like CI, in that the goal should always be to ensure that the code-base is stable enough to release at any time. Though I do not see the point in actually releasing builds like that. (Building, yes, releasing, no) 20 releases in 3 days? My issue would be the extra overhead of sifting through issues encountered with version x.y.z.1345 , .1347, .1352, .1356, .1357, ....
Yeah, if there's an issue raised you can always tell customers to "try a later build" but often they're busy enough as it is and won't want to upgrade unless they know the issue is fixed, or the feature has been implemented. I recall a bit of a rant about people that raise issues with seriously out-of-date versions... The more releases you put out there, the more fuel for this kind of annoyance.
I guess it really depends on the customer, and the platform. For web apps where there is only 1 "live" deploymment (typically a beta sandbox) then I like to update these quickly to give visibility of progress, adjustments, and such. For deployed applications (RC's etc.) I prefer to keep these less frequent. (i.e. 1 every few days or per week.) There are a lot less versions floating around to keep track of.
Krzysztof,
Think about conditional compilation, writ large.
My build process understand that some things do no belong in certain profiles, and can re-write them on the fly during a specific compilation
Steve,
I release every single time I commit.
Last week we had at least one release per day, today we had two.
I am not talking about builds, I am talking about something that customers have & use.
And yes, I am talking about a win app, not auto upgrade.
It does mean that I have more versions to support, but it isn't really that hard to do so, and the benefit of the rapid feedback cycle (you have a problem, it is fixed in a very short time) is enormous.
@ayende,
Conditional compilation is the first thing that came to my mind, but it didn't fit the "branched automatically" part.
The rewriting on the fly sounds interesting though. Do you plan to blog about this?
Krzysztof,
Well, it is pretty simple, we re-write the project file, dropping / including some things, modifying project wide options, etc.
The fun part is that the project rewrite is automated and convention based.
cool. I've been actually thinking about writing such thing for keeping Castle's Sliverlight projects in sync with the full-.NET ones.
That would be cool instead of having to maintain to sln files.
What is the definition of "Friction"? Is it a term related to coupling or is this a new term in software development
My take on friction is that it's any development activity that is wasteful. For instance, the idea of creating or updating static content (like updating mailing address or phone number) might involve searching, replacing, and then reviewing all of the affected pages produces a lot of friction and slows down the goal of making some simple content on the site.
Instead, spending some time to organize the site better (so your contact info can be updated in one place) would reduce friction a lot - fix it in one file and deploy.
Even better would be to deploy a content management system so that the process of managing content on the site is completely removed from the development team.
Of course, in both of these solutions, it's important to consider ROI. However, it costs a lot of money to run a development team for a day, and I'd sooner have them doing harder work (like writing business logic) than grunt work (like updating content).
However, that's just me. :)
Comment preview