+972 52-548-6969
Zero Friction & Maintainability
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
Comments
Excellent last paragraph at the end. Very succinct.
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?
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.
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.
Coupled fitness landscapes
Tobin,
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
Joseph,
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
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