http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Interesting 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. http://ayende.com/3320/zero-friction-maintainability#comment12http://ayende.com/3320/zero-friction-maintainability#comment12Sat, 24 May 2008 04:15:06 GMT 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. http://ayende.com/3320/zero-friction-maintainability#comment11http://ayende.com/3320/zero-friction-maintainability#comment11Tue, 20 May 2008 15:09:08 GMTExactly 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. http://ayende.com/3320/zero-friction-maintainability#comment10http://ayende.com/3320/zero-friction-maintainability#comment10Tue, 20 May 2008 15:06:17 GMTChad 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. http://ayende.com/3320/zero-friction-maintainability#comment9http://ayende.com/3320/zero-friction-maintainability#comment9Mon, 19 May 2008 14:16:26 GMTAnother 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 http://ayende.com/3320/zero-friction-maintainability#comment8http://ayende.com/3320/zero-friction-maintainability#comment8Mon, 19 May 2008 06:06:11 GMTJoseph, Huh? I am not following http://ayende.com/3320/zero-friction-maintainability#comment7http://ayende.com/3320/zero-friction-maintainability#comment7Sat, 17 May 2008 07:09:52 GMTTobin, 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 http://ayende.com/3320/zero-friction-maintainability#comment6http://ayende.com/3320/zero-friction-maintainability#comment6Sat, 17 May 2008 06:56:27 GMTCoupled fitness landscapes http://ayende.com/3320/zero-friction-maintainability#comment5http://ayende.com/3320/zero-friction-maintainability#comment5Fri, 16 May 2008 23:04:22 GMTI 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. http://ayende.com/3320/zero-friction-maintainability#comment4http://ayende.com/3320/zero-friction-maintainability#comment4Fri, 16 May 2008 21:38:53 GMTHow 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. http://ayende.com/3320/zero-friction-maintainability#comment3http://ayende.com/3320/zero-friction-maintainability#comment3Fri, 16 May 2008 19:50:10 GMTWow, 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? http://ayende.com/3320/zero-friction-maintainability#comment2http://ayende.com/3320/zero-friction-maintainability#comment2Fri, 16 May 2008 17:39:53 GMTExcellent last paragraph at the end. Very succinct. http://ayende.com/3320/zero-friction-maintainability#comment1http://ayende.com/3320/zero-friction-maintainability#comment1Fri, 16 May 2008 17:21:32 GMT