A danger of machinable software engineering factory: average style of programming.
The problem with software engineering methodologies is that they often promote a kind of "average" style of programming, often leading to mediocrity, or even worse, unnecessary overbloatedness. My favourite quote illustrating this problem comes from an excellent book by Jon Bentley, "Programming Pearls":
Problem 5 describes a class exercise that I graded on programming style. Most students turned in one-page solutions and received mediocre grades. Two students who had spent the previous summer on a large software development project turned in beautifully documented five-page programs, broken into a dozen procedures, each with an elaborate heading. They received failing grades. My program worked in five lines of code, and their inflation factor of sixty was too much for a passing grade. When they complained that they were employing standard software engineering tools, I should have quoted Pamela Zave: "The purpose of software engineering is to control complexity, not to create it."
—Jon Bentley, "Programming Pearls", p.123
I think that Java-like languages coupled with "enterprise" engineering technologies pretty often lead to such an over-bloated programming style. They are psychologically promoting such a style, which is one of the major reasons I don't like Java, and, I think, one of the major reasons one can often see poorly-performing Java programs around.
Don't misunderstand me: these technologies have their place and are probably a good thing in teams with 100+ members, but I think they are disadvantageous in smaller teams such as ours. Here, the organic growth way of software development, with frequent redesign and rapid prototyping and trials and rewrite, is what I prefer. I think this method leads to a better product. And while it's relatively expensive to do such an organic development in languages like Java, it's very natural in Common Lisp or Python.
Paul Graham puts it this way:
- Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anyway.
- Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work.
—Paul Graham, "Why Arc Isn't Especially Object-Oriented" http://www.paulgraham.com/noop.html
Let me finish with another favourite quote from Paul Graham, the author of what has become the Yahoo! Store online system:
"A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried."
—Paul Graham, "Beating the Averages" http://www.paulgraham.com/avg.html