Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,124 | Comments: 45,475

filter by tags archive

Zero Friction & Maintainability

time to read 1 min | 200 words

You probably heard me talk about zero friction and maintainability often enough in the past. But they were always separate subjects. When I prepared for my Zero Friction talk, I finally figured out what is the relation between the two.

I talk about zero friction as a way to reduce pain points in development. And I talk about maintainability as a way to ensure that we build sustainable solutions.

Let us go back a step and try to realize why we even have the issue of maintainability. Bits do not rot, why am I so worried about proactively ensuring that we will keep the code in a good shape?

As it turn out, while code may not rot, the design of the application does. But why?

If you have an environment that has friction in it, there is an incentive for the developers to subvert the design in order to produce a quick fix or hack a solution to solve a problem. Creating a zero friction environment will produce a system where there is no incentive to corrupt the design, the easiest thing to do is the right thing to do.

By reducing the friction in the environment, you increase the system maintainability



Excellent last paragraph at the end. Very succinct.

Tobin Harris

Wow, that's a briliant observation. It's going in my notebook.

Time pressure is probably the major creator of environmental friction that leads the developer to subvert the design, have you talked about any others?

Chad Myers

How many times have you experienced, or heard of a story where Company A hired brilliant architects/designers who built an amazing system and then eventually moved on to other projects or employers and the next wave of development team basically tanked the quality of the software?

Like you said, Ayende, it's not just enough to create a good design, you must create the design and the conventions and the tooling around it to make it clear to future waves of development teams what your intentions were and how to keep the software design in good fitness.

I like your previous posts about enforcing design conventions via tests to prevent future maintainers from violating those conventions that they might not have been aware of.

One of those tests is worth 100 pages of documentation, in my opinion.

Symon Rottem

I think the other point that's worth making is that the developers with a working knowledge of the application also rots over time. The result is that people far down the track who have no historical understanding of the application's codebase need to make changes or fixes. Without a good, maintainable application design that is intention revealing a newer set eyes will take longer to get traction when attempting to get up to speed.

Ayende Rahien


Sure. Complexity is a huge thing as well.

I can't figure out what I am supposed to do. Let us just write the business logic in the Button1_Clicked method

Ayende Rahien


Huh? I am not following


Another source of friction can be a changing external environment. Maybe the data volumes go through the roof (or were not properly quantified in the first place) or the use of the software has changed.

The design of a piece of software (nearly) always goes past the point of 'we really should refactor the design to cope with these new requirements' before someone actually does it.

Which brings another point: the design of a system is a living thing and will always degrade with respect to the requirements or the technology. The common enough idea that you get a bunch of smart developers to write a system and then carry on the maintenance of the software with (cheaper) mediocre developers is flawed. Design is an ongoing process that lasts the whole lifetime of a system

J.P. Hamilton

Chad has it right 100% but I think it's even worse than what he describes. The way I see it is that a lot of companies do the exact opposite of what they need to do after an app has moved into production. They find the junior-most developers they can find to maintain it. It's crazy. They just spent a couple of million building the software and now they want to skimp on the part that counts the most.


Exactly JP Hamilton.

I always risk ridicule when I post because I'm usually oppossed to "rocket science" solutions.

The suits always move scientist on to new projects, the juniors take over and kill the uber cool software, then the suits re-assign the scientist to get the now "pile of crap" software running again - of course with no time and no budget left.

There is nothing wrong with rocket science software at all - just dont use it on any business production system that you want to deliver and never have to work on again.

Even juniors can keep simple software running - usually.


Oh, I forgot to add, that's why scientist have a short half-life at all jobs, they aren't interested in writing simple software.

Thankfully the solution to that is easy, go independent. No boss and move on to the next job when you get bored. That's what I do anyway.


Interesting insight, and it is the number one reason for sacrifcing quality that I have seen. And I'd love to work for a company in zero friction envirnoment but I've never found one.

Gotta love when contracts are signed and dates committed to without even discussing the possibility with someone famillar with the code base.

Comment preview

Comments have been closed on this topic.


  1. The design of RavenDB 4.0: Making Lucene reliable - 6 hours from now
  2. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - about one day from now
  3. The design of RavenDB 4.0: Physically segregating collections - 2 days from now
  4. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 3 days from now
  5. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 6 days from now

And 13 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    02 May 2016 - You want all the data, you can’t handle all the data
  2. The design of RavenDB 4.0 (13):
    28 Apr 2016 - The implications of the blittable format
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats