The SquizLog

Java is worse than COBOL

Really?

That's the assertion of Robert L Glass but don't let this provocative statement distract you from the words of wisdom contained in his book, Facts and Fallacies of Software Engineering.

To be fair to Glass, he actually says:

COBOL is a very bad language, but all others (for business applications) are so much worse.

This is so-called fact 30 amongst Glass's collection of 55 facts and 5 + 5 fallacies.

Actually, I'd call them well founded opinions rather than facts and fallacies. But, as you can see, Glass is fond of alliteration. And like all opinions, those that Glass posits are open to debate. I for one disagree with fact 30. Many contemporary business applications are web apps and Java is, in my humble opinion, much better suited than COBOL to the task of developing them. I'll leave it at that for now.

My real purpose here is review Glass's book. It deserves attention.

The practice of software development is improving all the time, which is a good thing. However, there are some lessons that have stood the test of time and we would all do well to heed them. Glass's opinions, based on a perspective of more than 40 years in the industry as both a practitioner and a member of academia, warrant careful consideration. In my opinion (which is based on a mere 22 years in the industry), most of his 55 facts and 5 + 5 fallacies are well argued and supported by reputable references. Some are likely to be universally accepted but, due to our tendency to ignore them, they deserve to be re-emphasised. Others, like the one above, are provocative but that is Glass's intention: to provoke the reader into giving serious thought to important software development issues.

So what pearls of wisdom can the reader expect to find in the book? The breadth of issues covered is comprehensive and includes topics such as people, tools and techniques, estimation, reuse, complexity, requirements, design, coding, error removal, testing, reviews and inspections, maintenance, quality, reliability, efficiency, research and education. Let me give you some examples of Glass's so-called facts together with my own opinions about them:

Fact 1: The most important factor in software projects is the quality of the programmers.

This should be self-evident. Yet, as Glass points out, we tend to ignore the utmost importance of people's contribution to software projects in favour of burying our heads in processes and promoting tools and techniques. This is not to say that processes, tools and techniques are unimportant. They are. It's just that they're nowhere near as important as people.

I couldn't agree more. At the same time I must admit that I have been guilty of ignoring this viewpoint on a number of occasions!

Fact 5: Hype (about tools and techniques) is the plague on the house of software.

It's easy to get sucked into hype about tools and techniques. I know I have been. Extreme Programming, Spring and Ruby on Rails have all distracted me in the past. And, in the present, AJAX has me intrigued. There's nothing wrong with being curious about new tools and techniques. However, the trouble starts when claims are made that they will provide revolutionary breakthroughs or order of maginitude increases in productivity and quality.

Glass points to evidence that nearly all "so-called breakthroughs" since 1970 have provided modest benefits (up to 35%) to software developers. And, as he reminds us in "fact 6", there is actually an initial loss in productivity until programmers have learnt the new tool or technique well enough to start accruing the benefits.

My reaction? I should know better than to get sucked in by hype. Perhaps I need to train myself to detect and critically evaluate hype before deciding to embark on learning all about the latest "best thing since sliced bread". On the other hand, I think it is important to keep an open mind to improvements that new tools and techniques may provide. Critical, evidence-based evaluation and careful judgement should be the key.

Fact 8: One of the two most common causes of runaway projects is poor estimation.

Yes! This most definitely strikes a chord with me and, if my experience is anything to go by, is undeniably true. It is so easy to give optimistically low estimates at the start of a project when, obviously, less is known upon which to base the estimates. Recently I have been involved in supporting user acceptance testing for a couple of projects. Yet again, this activity has taken more effort than was anticipated. Why do we never learn?

Glass sums it up:

We do estimation very badly in the software field. Most of our estimates are more like wishes than realistic targets. To make matters worse, we seem to have no idea how to improve on those very bad practices. And the result is, as everyone tries to meet an impossible estimation target, shortcuts are taken, good practices are skipped and the inevitable schedule runaway becomes a technology runaway as well.

Fact 21: For every 25 percent in problem complexity, there is a 100 percent increase in solution complexity

This little known fact stems from a paper by Scott N Woodfield entitled "An Experiment in Unit Increase in Problem Complexity" published in IEEE Transactions on Software Engineering in March 1979.

If nothing else, Glass would like readers to remember this fact. Why? Because it underlines so many other important facts to do with the business of developing software. When we realise how complex software is it is little wonder that, for example, people are so vital to producing good software and estimation is so difficult.

Fact 23: One of the two most common causes of runaway projects is unstable requirements

"The evil twin of optimistic estimation", unstable requirements result from customers and users only having a vague idea of the required solution at the outset of a project. Naturally this makes it difficult for developers. Try as they might to nail down a definitive statement of requirements, at some point in time developers and customers must agree that the current requirements are good enough for development to start.

It is commonly accepted that requirements change throughout a project and a system's life cycle. The challenge is how to manage those changes. In my experience, documenting initial requirements via use cases and prototypes works well. From then on it is vital to manage changes in requirements via formal change requests. Unless you have the luxury of being in a situation where the Extreme Programming Planning Game, together with a resident customer, is applicable.

More "Facts" (and "Fallacies")

So there are my comments about five of Glass's "facts". To give the reader a taste, here are five more (some of which you may feel like contesting):

Fact 28: Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.

Fact 33: One hundred percent test coverage is still far from enough.

Fact 37: Rigourous inspections can remove up to 90 percent of errors before the first test case is run.

Fact 42: Enhancements represent roughly 60 percent of maintenance costs.

Fact 46: Quality is a collection of attributes.

And there are many more that are worth exploring. Each so-called fact is presented in a consistent format. A discussion is followed by Glass's assessment of any controversy surrounding it. Finally, a list of sources and references is provided.

Not to be content with fifty-five facts, Glass rounds out his book with ten (or five plus five to preserve the alliteration) fallacies.

Conclusion

Whilst you may share may opinion that Java is indeed a superior programming language to COBOL, I hope I have convinced you that other opinions of Robert L Glass presented in Facts and Fallacies of Software Engineering are well worth heeding. If you are involved with sofware development, I heartily recommend that you read this book, spend some time thinking about the issues that Glass raises and learn from his experience and research.

Unless, of course, you would prefer to make the same mistakes that he documents all over again!

Posted to Software Development by Keith Pitty