Why is it that so many program generators generate code that is virtually unreadable.  Granted, one of the main advantages of a program generator is that you don't often need to read the generated code, just execute it.  But is really that hard to generate code that maintains indentation and some semblance of a coding standard and naming convention?  Actually, I already know the answer.  I have written code generators, and you can have them create code that can be maintained outside the generator.  Most generators can only get you to 80- or 90% of the way to the final solution (many, no even that far).  Since the generated code is un-maintainable, you end up designing the solution around the tools at hand.  Frequently, this is good enough, and well worth the productivity gains.  You only need one or two people who really understand the tool to design the solution, and then a bunch of people who understand the language involved well enough the write the code snippets at all the exit points that the designer pointed out.  When the user requirements change, or it is discovered that a key business concept was misinterpreted, you simply toss out that section of the design, re-design it and introduce new code snippets.  Most people aren't even aware that they are using a code generator, and often the organizations that create the tools purposely make the generated code un-maintainable without their tools.  Again, if the life expectancy of your application is a few years, then no problem.  This is a great approach.  If you expect your application to be in service for many years or decades, then this lock-in poses a problem.  The tool needs to be at least a year ahead of the technology, so that you can spend that year adjusting your application to the upcoming technology.  If the tools needs to be a year ahead, and it takes them a year to revamp the tool, then they need to know the future technology 2 years before it is required.  Do you know the API's and the platforms that will be in demand 2 years from now?  What you end up with is an application that is always a year or two out of date.

Sometimes the problem at hand is one that cannot be resolved with the tools as published.  The tools can get you very close to the solution, but then you want to abandon the tool and work with the generated code to finish up.  Yes, this means that you can no longer leverage the tool for maintenance.  This is why it is critical that the tool generate maintainable code.  Too often I have been burned by using an application framework with no source code available to me.  Then some great new technology comes out, and there is demand for my application to leverage the technology.  The tool was written before the technology was known about, so it did not consider this.  Now I'm stuck.  How do I get my generated application designed for the blackberry to leverage the Android or iPhone?  How do I leverage some of the features coming in HTML 5 when my generator didn't have this in mind.  My solution is to pick an open framework, where I can see the source and stray from the tools if I want or need to.  When the tools catch up, I can then go back into the fold and pick up the productivity gains.  I'm happy and my user base is happy.

I am an engineer.  I have about 35 years of experience programming.  I have read thousands of programs, designed, written or maintained hundreds.  In all that time, with all that experience, I have come to the conclusion that good software is not a science.  It is an art. 

You certainly do need a good foundation in math, and you need to be able think in a structured manner.  You also need to know the strengths and weaknesses of the languages you are using and the paradigms you will be leveraging (Objects, structures, layers, hierarchy, relational or any other abstraction of reality you will be bringing to bear on your problem).  You also need to ability to think in the abstract, and often multiple layers of abstraction.  but more than that, you need to be able see the beauty and the balance of the code you have created. 

Well written code is a joy to maintain.  You can navigate it easily, find your way to bits that need attention, and then do what needs to be done.  A consistent programming standard and a naming convention that makes sense makes but easier to find and fix, and new features easier to seamlessly integrate.  Just standing back and looking at the code, the shape of the indentations, can often point to potential problem areas where the code is not balanced and the shape isn't quite right.  A consistent method allows you to zoom straight into the meat and bypass all the fluff. 

It is easy to find programmers who have all the right technical skills.  They can show countless examples of software they have written and that is in production somewhere or other.  But if you scratch past the surface, you will find that the software has bugs (all software has bugs), and that the systems they have written are scheduled to be replaced within a few years of being introduced.  Or that the cost of maintaining these systems rises exponentially with age, as various fixes and patches clutter the code into an unrecognizable mess of spaghetti.  With a bit of searching, you can find people who have a love of the art of programming, but their productivity is so low that you can go bankrupt before the benefits of their art can be realized.  To be sure, you do need to spend a significant amount of effort designing before programming, and then program with a great deal attention paid to the details, but there is a balance.  Part of the art is being able to arrive at a workable solution in a timely manner.  Perhaps not the perfect, or ultimate solution, but a solution that will resolve the issue at hand, and still be a work of art. 

The truely hard part is finding the programmer that has that dream-like combination of passion for the art, the technical skills and the ability to follow a solution to completion in a timely manner.  Is it just me, or does anyone else have the same problem with finding good talent?