Development principals
Here is really great post on principals to write maintenable code. More over this can be extended to improve supportability of the products.
Most of the developers are doing development only! It does not sound like a problem for you…I thing we are at the exact barrier between real development and hobby work. I’m not that fan of Agil development as it does not work well if not apply correctly and with a minimum of knowledge, experience and willing to do it. Nevertheless, Agil methodology as the real advantage to melt the concerns and responsability of QA, dev, CM over the entire team. From what I’ve seen, usually, development task are only 20 to 40% of to whole process to implement new features (and I don’t take into account the maintenance, support and bug fixe after release). Do not use the fake argument that it depends on the environment (Language, Framework, QA automation rate…etc), it’s just wrong. I prefer by far having a developper that knows less about a language or a framework but concerned by CM, QA, comprehensiveness and maintenability of features/code than a rely strong developer that will force to use the last framework release that he knows and break build process…even if his coding skills are higher. To make it shorter: don’t care about improving efficiency about 10% on 20-40% of the process, but I care if it’s on 60%-80% of the process plus maintenance, evolution…etc.
A sentence from the article that are fiond terribly true: “there is an inflection point where a coder mindlessly spewing out code transforms into a thoughtful software craftsman capable of creating maintainable code. That inflection point happens the day a coder first stops, lifts his/her nose out of the coding window, and says to him/herself “where should this code go?”.
I’ve seen this many times and is named “Seperation of concerns”. That does not mean using Spring is mandatory do code correctly :-), but as soon as a developer start to think this way, he will improve maintenability, componentization, and avoid spagetty development with useless interdepedencies. We see new languages as Ruby, Python that are marketed as “less code to implement the same feature” than with other languges as Java and C#. I agree that simplicity is fondamental and less code also, but this should not lead to weird code that can’t be maintained: if seperation of concerns leads to 3 additional lines of code to do a back-and-forth between 2 layers…that’s good.