To invent takes guts. And sometimes the process involved in innovation isn’t always a straightforward path. It’s fraught with failures, dead ends and U-turns.

Someone once said “Invention is a blind man in a dark room looking for a black cat that probably isn’t there”.

My take on this is: probably because human mind is unique in thoughts of how to build software (service/application etc.), as for bridge there are physical demands and requirements from architectural point of view that limit the thoughts – thus making building bridges easier task due to laws of nature that do not apply so much for building new endless permutations of code for endless new expectations by users of software.

I’m just finishing reading your book. Having just retired from a 40 year career as a programmer, software designer and development team manager I think you captured perfectly the psychology, issues, frustrations and joys of the software development enterprise.
Good work!!

On software project management “disaster recovery”, when really bad things happen to software projects (and they do) it is mainly due to lack of experience or lack of talent. Putting the right people in place is the first step and by the way, source code control, daily builds, daily tests are bread and butter among competent software developers, not part of a silver bullet to “fix” a project in crisis.

Frameworks like EJB and web development are the COBOL of today, programmer straitjackets that “cripple the mind”. Headed for obsoletion and someday to be relegated to the status of cautionary tales, technologies such as these are frequently put forward as Silver Bullets. In education, the learning of so called “hard” concepts such as pointer manipulation and garbage collection is regarded by many as “obsolete”. Those who disagree are treated with the same contempt as the boy who saw that the emperor had no clothes. To solve many of software developments current ills, begin your revolution in Universities.

The “big picture” that computing students search for is probably so big that none of us can see it. Software development “HARD”? Give me a break. Of course it is hard. Bridge building is hard. Anybody wise will tell you that nothing worthwhile is easy and if it was everybody would be doing it. In fact, the most fundamental software blunders were usually made by people who lacked experience and made wrong choices, underestimating the difficulty of a task being undertook, not executing due diligence in their investigations or perhaps they simply were unqualified. Of the people who have made such mistakes, some never see the error of their ways, or never accept responsibility, or don’t stick around to clean up the mess. However, there will always be a few who are eager to put their hands up, point out the flaws in what they have built and want to do it again, differently. We call these people engineers, those who some day should take on a project that is the software equivalent of the Bay Bridge replacement. But they will never complete such a project “without a hitch”. That is never how the software engineer expects it to be.