[RogerL]

A very wise man said "there is no silver bullet". Yet we keep trying all these schemes to automagically solve what are hard optimization problems only amenable to heuristics and deliberate, intelligent introspection. Very simply, you cannot run some tool to measure the information density of a large project. Graphical programming isn't going to turn a bunch of marketers into programmers. Doing user stories and forcing people to stand up as they talk isn't going to remove all the need for planning and tracking. And so on.

You know how I figure out if something can be improved? I dig in, understand it, and then look for ways to improve it. If I don't find anything, of course it doesn't mean there is no room, but I'm a pretty bright guy and my results are about as good as any other bright guy/woman.

I was subjected to endless amounts of this because I did military work for 17 years. You'd have some really tiny project (6 months, 2-3 developers), and they'd impose just a huge infrastructure of 'oversight'. By which I mean bean counters, rule followers, and the like - unthinking automatons trying to use rules, automatic tools, and the like. Anything to produce a simple, single number. It was all so senseless. I know that can sound like sour grapes, but every time I was in control of schedule and budget I came in on time and on to under budget. But that is because I took it day by day, looked at and understood where we were and where we needed to go, and adjusted accordingly. Others would push buttons on CASE tools and spend most of their time explaining why they were behind and over budget.

I like Fowler's conclusion - we have to admit our ignorance. It is okay to say "I don't know". Yet some people insist that you have to give an answer, even if it is trivially provable that the answer must be wrong.

[chromatic]

Please excuse this small rant.

If you're referring to Fred Brooks, he wrote "[T]here is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity." (emphasis mine)

The surrounding context makes his comment a very specific prediction which means something different from what most people claim he meant. Much of the rest of his essay suggests techniques which address the issue of essential complexity and which, when applied together, he hoped would produce that order of magnitude productivity.

Perhaps there was no single such improvement in the years 1986 to 1996, but when people use the phrase "no silver bullet" to dismiss potential improvements in productivity, I believe they're doing Brooks and the rest of us a great disservice.

[RogerL]

I'm confused. I was pointing out that you cannot do something simple like count LOCs, run a CASE tool that spits out cyclomatic complexity, or other things, and instantly measure productivity. How is that not what Brooks was saying? You don't bean count your way to better software, you manage the inherent complexity. Daily, hard work, understanding all of the parts, and so on.

[jacques_chester]

You missed a key point of the essay, which is that no matter how much progress we make in accidental complexity, essential complexity does not go away.

[chromatic]

Of course that's the key point of the essay, but I've never observed that anyone who says "There's no silver bullet in productivity" has made it past the desire to misuse the title of a Fred Brooks essay to support a middlebrow dismissal to the nuance of distinguishing between accidental and essential complexity.

After all, much of programming culture is stuck on the idea that the clarity of syntax of a programming languages to novices is more important to maintainability of programs written in that language than domain knowledge, for example.