There are some discussions going on at this time on the community around the topic of
writing maintainable code and the different trade-offs a given "project reality"
might force on the developers involved in it. Very much worth reading and highly
recommended everyone reads and participates. Jeremy Miller beat me to it with some
good comments, as well.
My own personal opinion on the matter is a bit of a mixed bag (and so at times I might
seem to contradict myself). On one hand, I find myself in total agreement with Ayende and Sam (just to name some of the most vocal proponents) that raising the level and knowledge of the developers that are going to be receiving the application is a critical step. I am a strong believer, learned from my own personal experience, that there's no amount of tooling and supervision/control that can "fix" the deficiencies of the team members themselves. It just simply doesn't cut it.
I believe says it best when he says that "Because my view is that having the developers learn a better way to build software is much less costly than continuing to produce software that is hard to maintain". I couldn't have said it better.
I am, however, sensitive to the dilemmas brought up by JDN and Frans Bouma, both of which have articulated their concerns and point of view in very provocative and thoughtful ways. I'm sensitive because I've found myself in their position a few times, and I've made the same choice they've argued in some of those occasions. However, my experience also shows that making that trade off, at those times I've made it, has eventually shown to have been a less than optimal decision.
Given this, I'm firmly in the camp that a) you should strive to avoid making that choice if at all possible, and b) you've got to be pragmatic about it. Sometimes, yes, organizational dynamics and politics play a role here, even if we disagree with it. So sometimes that might be the right choice to make, but rarely (if ever) for purely
technical reasons. And the whole "other developers might not get it" is, in the end, a red herring and tends to obscure the real reasons and motives behind it.
Why is it a red herring? Because it is usually a sign of the "we want to have a few highly skilled developers and lots of unskilled, cheap developers for the 'easy' stuff" mentality that pervades a lot of the companies in our profession, and it's just one I can't agree with. It's not that everyone should have 10 years of experience building extremely complex applications, but rather that everyone should have the opportunity to do their work to their best of their abilities. Inevitably, I find that this sort of mentality tends to set bounds that developers can't later cross easily without a lot of push back from management and the organization, leaving unskilled developers without a path they can collaborate with their more skilled, more experienced peers to grow their own skill set.
In many ways, this is a topic that strikes close to home for me, for several reasons. First of all, this kind of discussion is one of the reasons I decided to quit my last job and start my own company. In my point of view, the whole concept that the people are the key ingredient that make/break a project is absolute key. It's not about how much experience and knowledge the developers have. This is a significant component, for sure, but one that can be acquired with time. What is absolute key is the attitude:
- A willingness to constantly learn and look for new opportunities for personal/team/product improvement.
- A commitment to satisfying the client/costumer/user.
- A commitment to being ethical, honest and professional about your work and your own capabilities and limitations.
- Awareness of your context and that of your project/product.
- Caring about what your doing and being enthusiastic about it.
- Being critical about your own work and those of others, even if your believe others are above you or have different responsibilities (say, project manager or architect). Note this is not about constantly criticizing other people's work; it's about thinking critically about what the work that's being done by the team as a whole and the results.
I've seen many developers that lack one of this. Some are just 9-5 guys [1] that just want to get through the day without caring about the end result. Others have no desire for learning new things or getting out of their comfort zone. Others simply don't care about what other people do or what they do, usually manifested by them saying they're done implementing something and when you go look it doesn't even compile. Others will just do what their told to do and never even stop considering if it makes sense or if indeed it is the best way to do it.
Like Ayende, I refuse to be just a replaceable cog in a big machine; I want to make a difference and continuously learn and grow my skill set. I wouldn't have it any other way.
So it's about lots of different things. I love working with people that are critical about my work; they make me be a far better developer, and by listening to their opinions and sometimes different alternatives they propose I myself learn a lot. Sure, it's sometimes hard to listen to it all, but it's much worth it.
Arguing about the right things
I think one aspect that has tended to mud a bit the discussion is that we put a lot of different things into the same bag, which makes everything more confusing. For example, some people have mentioned MVP/MVC, ORM and TDD as important aspects in achieving maintainability, which some people have reacted a bit against.
From my point of view, the problem here is that we're mixing practices with tools. For example, TDD is a practice, and one that indeed is (imho) very important in facilitating the creation of maintainable code. But by itself it is no silver bullet (my friend Sam, for example, always talks about using the full set of 12 practices proposed by eXtreme Programming, not just TDD).
On the other hand, ORM and MVP/MVC are tools (yes, patterns are just design/coding tools, in the end), and sure, they can significantly help in producing maintainable code. But they are just tools, and you have to evaluate their impact and usefulness in each case. Some projects might simply not benefit from using ORM
(for example, this is rarely a useful component in the integration project's I've worked on), while it might reduce the amount of hand written code in your typical business application (and less code will always mean more maintainable code). But others might prefer for certain applications the use of code generation instead of an ORM and, you know what? That might be a perfectly valid choice in the context they're in. What's key here is
that they've done the analysis and choose what they believe it's best for them given their context.
Note: It's perfectly possible that the choice still turns out to have been the wrong one in the end, given that many times you start out with limited information from which to make your decision; but that's life.
It's about the future
One key issue I've seen again and again is that many developers don't even care about writing maintainable software, simply because they're not the ones that will have to maintain it. It's a very pervasive mentality in some circles that has been brought, in part, by the outsourcing of software development (something I make my living off, by the way). For
example, in Colombia, a lot of companies have no internal software developers anymore, so external providers come in, create the initial release of an application and go away, many times never to see that code again except for one or two fixes during stabilization.
This means many developers don't really learn about the value of writing maintainable software because they it's easier to justify to yourself the writing of poor code when you think "I'm not going to maintain this later on, so why should I care?". This is not only a very egotistical point of view (and easy to fall on) but also ethically challenged. But what's worse is that it is a complete fallacy: you're still maintaining your code, and every day you write poor code in a project it's more code you have to maintain. It's just a lot of people seem to think otherwise and lie to themselves as a defense mechanism against the pain their going though every day on their project.
[1] there's a difference between wanting to have a life outside of work (good) and not giving a shit (bad).
