Product development is more complex than developing projects. We all know that. Any product is expected to be in the market for next 10 years (at least that’s the assumption made during the start of development). Hence the development and maintenance effort is also more.
When it comes to maintainability, every application development effort starts with the intention that the code has to be maintainable. I do not think anyone will have other intention on this aspect. But, even after having the right intention, a year of development, you don’t get to see maintainable code in majority of the code developed. You may hear from the architect/technical lead that certain areas of code are bad and we may have to refactor/rewrite them. The logic has leaked to the presentation (or other layers) is one of the common concerns I have heard (at least most of the times).
Why does it happen all the times? If you are old timer and have done development for quite some time, then your immediate answer is you guys do not have proper code reviews. Yeah, in principal this is an excellent practice, but practically it is very difficult to implement.
Why do you say so? Assume that you had the luxury of starting a development work from scratch and having an architect in the development effort. You get some initial design, the basic structure is been put together (Layers, basic structure, blah, blah…), initial unit tests are written to prove that the structure/design works fine. You add more members to the team. They start writing code. Even though you can educate your developers about how the code is written, but everyone brings some baggage with them (culture, how they worked in previous projects, companies etc…). This baggage is very difficult to leave and old habits never die. That’s when the code starts getting decayed.
Now, if you have an architect (who is a real architect), as a manager you will be tempted to use him in some development work rather than keeping him overseeing the development effort (how the development is happening, how new features are been plugged and any damage control). Good Architects are expensive people and no company will be interested in keeping them to oversee the development (as it has a direct impact on your margins). This is where the conflict comes in. When the architect is pulled into some regular development work, he doesn’t get a chance to oversee the development full time.
You can put in practices like FXCop and code analysis tools along with your Source Control System/Build System, but IMHO, it’s very hard to figure out these logic leakages etc… from these systems.
I was with a company some time back and the development manager used to do random code reviews, yell at people in the work area. Last year, I and Sendhil were at a client location and we found their architect calling people to his area whenever he found some bad code in the checked in version. I initially thought it’s a bad practice and you do not trust your own people. Over the period I have realized that it’s not possible to have your code under control unless you have some tight measures in place (your architect on top of the source code every day). Alternatively, you can try pair programming. But I am not sure how many companies are there which does pair programming on a regular basis. Without all this in place, I am sure you will end up in embarrassing situations with your code quality very often than what you can think.
I am sure this will present cultural issues in your environment (as other teams may not be doing). But at the end we are here to write quality code/develop software. Ultimately as a developer, you are not doing any charity work or your company is doing any charity work either. I am sure it is possible to educate this with the new members and make it as part of the culture.