I’m now one of many frequent readers of Coding Horror, a blog by Jeff Attwood about “programming and human factors”. In a recent entry, “Escaping From Gilligan’s Island”, Jeff wrote about classic mistakes in software development processes. I felt inclined to comment on one of the comments:
> The big difference between a beginning developer and an experienced one is that an experienced one will think about how their code may change in the future. They already thinking what types of changes and modifications that will be added, and write the code to make doing those modifications easy. Beginning developers tend to write their code as if it will never change.
I agree with your picture of the beginner, but I’d add another step: The beginner writes code that works now, but is hard to change tomorrow. The experienced developer writes code that works now, can adapt to a few changes tomorrow, but fails a week later, due to too much code that was writte to provide more flexibility.
The expert writes code that works today and refactors it tomorrow and every time he needs to add something, always aiming for the simple and clean solution.
Its easy to find projects that are overloaded with so much unnecessary flexibility that it is impossible to maintain them.
Someone else, named Aaron G, was so friendly to put this into a better formulation, adding another dimension to the list:
> Jörn: “The expert writes code that works today and refactors it tomorrow and every time he needs to add something, always aiming for the simple and clean solution.”
* Incompetent developers code without a plan (no flexibility).
* Mediocre developers code with an arbitrary, contextually-irrelevant plan (confusing, unusable flexibility).
* Expert developers are aware of their context, can see realistic future points of failure and areas of change, and plan accordingly (actual flexibility). In some (rare) instances, “accordingly” may even mean “not at all”.
* Charlatans insist that they have a one-size-fits-all plan, and redefine “success” based on the context. They offer the same long-term productivity as incompetents, but come with the additional overhead of dysfunctional relationships and other management headaches.
I guess I haven’t yet met a real Charlatan in a software project. I wonder how long it takes to identify one, eg. before or after a project crashed.
The expert writes code that works today and refactors it tomorrow and every time he needs to add something, always aiming for the simple and clean solution.
Well said, Jörn!