Ayende @ Rahien

Bruce Onder commented on Reducing friction as a standard operating method

Sat, 21 Nov 2009 16:46:58 GMT

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. :)

T commented on Reducing friction as a standard operating method

Fri, 20 Nov 2009 19:29:50 GMT

What is the definition of "Friction"? Is it a term related to coupling or is this a new term in software development

John Simons commented on Reducing friction as a standard operating method

Fri, 20 Nov 2009 06:44:36 GMT

That would be cool instead of having to maintain to sln files.

Krzysztof Kozmic commented on Reducing friction as a standard operating method

Thu, 19 Nov 2009 08:18:33 GMT

cool. I've been actually thinking about writing such thing for keeping Castle's Sliverlight projects in sync with the full-.NET ones.

Ayende Rahien commented on Reducing friction as a standard operating method

Thu, 19 Nov 2009 07:54:13 GMT

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.

Krzysztof Kozmic commented on Reducing friction as a standard operating method

Thu, 19 Nov 2009 07:26:04 GMT

@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?

Ayende Rahien commented on Reducing friction as a standard operating method

Thu, 19 Nov 2009 07:18:14 GMT

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.

Steve Py commented on Reducing friction as a standard operating method

Wed, 18 Nov 2009 21:19:04 GMT

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.

Rafal commented on Reducing friction as a standard operating method

Wed, 18 Nov 2009 20:58:28 GMT

@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'.

Brian commented on Reducing friction as a standard operating method

Wed, 18 Nov 2009 16:22:08 GMT

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.

BjartN commented on Reducing friction as a standard operating method

Wed, 18 Nov 2009 11:20:03 GMT

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 :)

Krzysztof Kozmic commented on Reducing friction as a standard operating method

Wed, 18 Nov 2009 11:18:33 GMT

"single code base that is being branched automatically by the build process" <-- huh? Can you elaborate on that? Sounds interesting