Tag Archives: Programming

Links

The Perils of JavaSchools

I’m starting to sound like a grumpy old man. (Those that know me should stop nodding their heads and agreeing now, please.) This is another “things were better in my day” post.

As I previously mentioned, both graduates and companies are complaining that university courses are not vocational enough. I personally dispute that. However I am generally in agreement with Joel Spolsky when he says that “Java is not, generally, a hard enough programming language that it can be used to discriminate between great programmers and mediocre programmers.”

Joel on Software: The Perils of JavaSchools

This all comes back to knowing “principles” rather than just implementation details. Java is a fine language for doing “real” things in, but since you don’t need to know much about pointers, recursion and some fairly standard algorithms, people tend not to learn the fundamentals. This is a great shame.

Opinion

Random Changes

When it first happened I was irritated. A few days later I was irritated that I was still irritated. It didn’t make any sense, it wasn’t a big thing and it shouldn’t have bugged me at all, much less still a few days later.

After a while I realised that my irritation was more rational than I initially thought so I started to write them down as a way of structuring them. And here they are.

So what went wrong? Well, first we’ll need a little background, although I’m sure you will appreciate that I can’t go into all the details.

My day-job involves writing code, enhancing and fixing a sprawling, ten year old application and this day was no different. For the previous few weeks I had been developing a small improvement to one of the reports. I had satisfied the requirements by modifying an existing report, including the occasional conditional where appropriate. Not my best piece of work by any means but I had spent some time on it, had some of myself invested in it in some small way. I checked in the change to our source control system and moved on to other things. A short while later someone reported a bug against it. Not an unusual occurrence with the very vague requirements I was working to and the general standard of my code, however one thing did surprise me — I was sure that I’d tested for and added code for that particular scenario.

It turns out that I was right. The problem was that somebody had completely rewritten my code. The new implementation was very elegant, more aesthetically pleasing that my hack. Remember that I never believed it was the best code I’ve ever written, so if the code actually worked correctly I wouldn’t have cared. But it didn’t. It had fixed one small problem with my code but had introduced at least one new problem, one that was far more difficult to fix than the problem it was trying to solve.

There’s a technical, software engineering, side to this and there’s the effect is had on me. If I was being grand I suppose I’d call that the psychological side. I would like to talk about both of these aspects.

First, let’s discuss the technical side.

When modifying a large, established code base I have always believed that the correct approach is to make as few, targeted changes as possible to get the job done. The problem with a non-trivial code-base is that embedded inside it is dozens of small tweaks that you would never think of making but the software has accumulated in the School of Hard-Knocks. Real life has a tendency to throw up scenarios that, theoretically, are not possible. No matter how good you are at writing code these things happen.

This changed violated this principle. That alone annoyed me.

Of course the counter-argument is that we should be continually refactoring the code. This is the Extreme Programming approach and is one that I have talked about previously. I do have some sympathy for this argument, except that in this case it t really apply. While the new code was undoubtedly cleverer than the code it replaced, it’s difficult to say that it’s better. When you’re writing code that may well be around in a number of years time it needs to be understandable. Writing clever code can be a disadvantage. A few extra lines of code, if they’re simple and easily understood, are often a good thing. It’s easy to forget that it’s not just the computer that needs to read the code.

Naturally the reason that people do this is that it’s much easier than reading and understanding the code, and this is probably more true in the language that we use than most (it’s a proprietary one that you won’t have heard of). So the author of the new code will have saved himself a few hours of work but by creating a clever yet difficult to understand alternative he has generated more work and confusion for legions of support analysts in the future. This costs the company time and money, although the author of the new code appears to be a super-hero as he checked in hundreds of lines of new code compared with my much smaller number.

The psychological aspects are less easy to define but in many ways are more important. Unfortunately I would concede that I am less capable of discussing them in anything like scientific manner. It’s not going to stop me trying, however!

The question at the centre of is all is: why do certain kinds of people like writing software? It’s a painstaking and fiddly task which requires unheard-of precision and attention to detail. Why would anyone want to do that?

I’m sure there are as many answers as there are programmers, but a common root cause would be the simple challenge of solving a complicated problem. There’s a certain satisfaction in completing something tricky and, even if you recognise that there are other ways of doing something, there’s usually a certain pride in the way you did it. It may not be the best, but it’s your way.

So really it’s one of those seven deadly sins: pride.

Also there is a large motivational aspect to it. At this point in the project I was already lacking my usual level of enthusiasm for a number of reasons that I won’t get into here. What kind of effect is someone unnecessarily rewriting my code going to have on me at this low ebb? Why would I want to write more code and make more fixes now? Surely it’s just going to get rewritten.

Note that I didn’t say “criticised.” I think an important aspect to get across here is that I am not above criticism. If the code had been improved, if the new author had discussed the options with me first and we’d agreed a way forward, I doubt that I would be writing this piece here and now.

Now there may well be some degree of bitterness here, however I think ll agree that there are both technical and human factors reasons why things should have been different.

Opinion

Joel On Software

Let’s cut to the chase: if you’ve read and enjoyed any of Joel Spolsky’s ramblings on the web you’ll like this book. Skip the rest of this review and just go buy it.

For the benefit of those that have not heard of him, who is this Joel chap and what is the book and his normal prose about? The “About the Author” section describes him as an industry veteran that writes an “anti-Dilbert manifesto” on his website. I can’t think of a better description, which is why I have shamelessly copied it rather than finding my own phrase…

He writes about software development at every level from bashing out code right through to strategy and he applies the same degree of pragmatism, common-sense and humour to every subject he covers.

The book is split into four sections and an appendix. In the first he talks about “the practise of programming,” which is the low level stuff. He starts with choosing a programming language (or, at least, why it’s probably not as important as you might think), moves on to the now almost classic “Joel Test” (Google it if you’re in any doubt how influential it has become), moves onto functional specs, schedules and the like.

Section two is all about managing developers. Personally, I think this is the part that he really excels at. Indeed, the best bits of the other sections are actually about the higher level stuff. One of the highlights is about what he calls “leaky abstractions,” basically that clever things that try to hide their underlying details tend to fall down in unpredictable ways. Ever got confused about the way a string class works in C++? This is the chapter for you!

The penultimate section is a random collection of articles, including his thoughts on the 80/20 myth, various business models and open source. I particularly like the piece on getting things done when you have no authority to do anything officially. Most books assume that you just need to learn what the right thing to do is, so it’s refreshing to find a book that deals in Real Life!

The final section is less relevant to someone like myself with a Unix background (and interest). There are three pieces on Microsoft’s .NET architecture. Nevertheless, I did read them and thought that he had some interesting things to say.

There is also an appendix, which is a “best of” collection of questions from the “Ask Joel” section on his website. This is perhaps the weakest section in the book and, although entertaining, most of the good advice in this section has already been expressed more clearly in earlier sections.

You can probably see by that I was impressed. It was an easy book to read — something that a lot of technical writers forget about — and even when I disagreed with certain things I could at least see where he was coming from.

The facts

Author: Joel Spolsky

Cost: $24.99

ISBN: 1-59059-389-8.

Buy from Amazon.co.uk.

Opinion

Coder to Developer

The concept

I liked the blurb on the back:

“This title addresses all of the skills required to effectively design and develop complex applications, including planning, building and developing the application and coding defensively to prevent bugs.”

It suggests that it can bring you from the stage where you focus entirely on the code to the point where you can take in a whole project, make it all work and delight your customers. Mike Gunderloy has 25 years of commercial experience and so has a lot to say.

As he points out in the early chapters, there is a lot of ground to cover. There is everything from actually writing better code, through to planning, risk management, release management and handling your team. He covers all of these areas, providing handy hints and war stories clearly gleaned from hard-won experience.

For example, I liked the way that he sticks to the things that you need to know, even splitting them up into categoories where it makes sense. Gunderloy seems to be as amazed as I am about how m any projects do not use source control, and he lists Three Levels of Source Code Control Enlightenment, from Opening Your Eyes (just six commands and many benefits!), to SCC Journeyman (which he acknowledges may be all many people need), through to Experts Only (which he spends so little time on that it’s difficult to know what the various options he talks about are for).

Windows Coder to Windows Developer?

What you’ve seen so far is praise for the general concept of the book rather than anything very specific. There’s a reason for that. For a general software engineering book, it’s strange that there is such a strong Windows and .Net slant. There is no need for such details and it will reduce its longevity and usefulness. Steve McConnell’s “Code Complete” is ten years old and is still relevant (even though a new edition has just come out). In six months Coder To Developer could well look dated.

There is also a question-mark over the accuracy of some of the information. For example, he credits the the iterative development process to Microsoft and Rational, forgetting Bohem’s spiral model predated both by well over ten years. He seems to be much more fluent in more recent practises like Agile and XP, which is commendable but seemingly lacking the foundations makes it difficult to put these newer methodologies into perspective.

But if you can ignore these problems, there is lots of good advice. He’s pragmatic ? using the good bits of, say, XP without taking the process as gospel ? and the writing is accessible and friendly. Even disagreeing with some of the early chapters, I still persevered as it wasn’t a dense or difficult read.

The facts

Author: Mike Gunderloy

Cost: $29.99

ISBN: 0-7821-4327-X.

Buy from Amazon.co.uk.

Opinion

Practical C Programming

Introduction

It sounded like just the kind of book that I was looking for. I wanted a refresher on C since I’d not used it for a while, and some pointers on ‘advanced techniques.’ The blurb on the back looked about right and the fact that O’Reilly published it clinched the sale.

“Practical C Programming” not only plans to teach you C, but also about style, debugging and the software life-cycle.

Content

The book is split into three sections: Basics, Simple Programming and Advanced Programming.

‘Basics’ introduces the language, leaving out much of the fluff and complex bits, but including much on style and ‘process’ — designing, building and maintaining your program. This part of the tutorial is well structured, only introducing new features of the language as and when they are necessary. It does not teach you how to program, rather how to write C. Since you must be able to program before you start the book, I consider the pace to be much too slow. If you already know how to program, why should you have to wait until chapter six before introducing the if statement?

‘Simple Programming’ finishes off what the last section started. It adds most of the more complex bits such as scope, bitwise operators, pointers, floating-point numbers and the C Preprocessor. Of course, the boundary between basic and simple is not well defined, but I would consider the for statement to be basic. This section also includes information on optimising programs which you might have thought would fall under the ‘Advanced Programming’ section.

The final section is much more terse and reference-like than the first two sections. It includes topics such as the difference between ANSI and Kernigan and Ritchie C, more on pointers, portability and some of the more dodgy parts of C such as the 😕 operator and goto statement. It also includes a section on modular programming (again, I would consider this to be in the wrong section) and ‘Programming Adages.’ For the experienced programmer, it is probably this last chapter that is the most useful. Reminders such as avoid side-effects and never put an assignment inside a conditional seem to go against the grain of conventional C wisdom, but are, indeed, correct and very valuable.

Conclusion

‘Practical C Programming’ is not a bad book by any means. Scattered through its 400-odd pages are dozens of useful tips and heuristics, many of which I’ve not seen in print before. It also manages to clarify some oddities, and the example programs are mostly well thought-out and clear.

The C tutorial is not in enough detail to help a true novice and is too chatty and basic for some people, like myself, who just want the facts. The annoying part is that there is a lot of information in there that I didn’t already know, but I almost didn’t have the patience to read it.

It’s also unusual to find a chapter on software engineering in a C book. Oualline has a nice discussion of design, source control and configuration management but it does leave you wondering why it is there. Sure, it’s an important topic, but there are huge books dedicated to this subject. He can not (and does not) even begin to scratch the surface.

What the book lacks is a clear focus. Is the book for a novice programmer? Is it for someone that doesn’t know C? Someone that does know C? Is it a reference? A software engineering guide? The real answer is that it tries to do it all, but only partially succeeds. A nice try but not a must buy.

The facts

Author: Steve Oualline

Cost: Approximately ?24.50 or US$32.95

ISBN: 1-56592-306-5

Buy this book from Amazon.com of from Amazon.co.uk.

Opinion

Oracle PL/SQL Programming

Introduction

The first point to note is that this book is published by O’Reilly. The second point would be that Steven Feuerstein is generally regarded to be one of the worlds leading PL/SQL experts.

Those two point, on their own, were enough to clinch the purchase just over eighteen months ago.

Content

The book is, to say the least, comprehensive. When I first started to use PL/SQL I would never have guessed that there was enough there to write a thousand page book, but there is.

It’s split into seven sections and twenty-six chapters, making it a good reference as well as useful to learn from. Section one, ‘Programming in PL/SQL’ talks about the history, block structure and style. I’m not entirely convinced that ‘programming style’ belongs in a book such as this, but it’s well written, useful and less intrusive than the similar treatment in “Practical C.”

Section two moves onto the ‘meat’ of the language and takes up over two-hundred pages in its own right — longer than the whole of some other texts! Feuerstein covers all this in detail and with great skill, mentioning not only how the language works but also, where appropriate, where it doesn’t work. This kind of honesty seems rare, especially in Oracle Press books!

‘Built-in Functions’ does exactly what you’d expect, and includes a thorough discussion on handling dates, a common area of confusion (I was pleased to find that it’s not just me…).

Parts four and five are, perhaps, the most clumsy sections. The first talks of ‘Modular Code,’ which I don’t see as being so advanced that it requires its own section. And part five discusses the ‘New PL/SQL8 Features’ which, again, don’t necessarily deserve a section on their own. I suppose it made writing the second edition easier…

The last section before the appendices is called ‘Making PL/SQL Programs Work.’ For those not familiar with server-side PL/SQL, let me point out that this isn’t as silly as it sounds. PL/SQL, until recently, had no debugging facilities to speak of. You can’t set break-points or single-step and even outputting trace statements to the screen is not trivial.

However, although the stuff that Feuerstein writes is interesting and might be useful to some, it’s not all it might be. For example, in the section on tracing PL/SQL programs (chapter 26) he talks about Oracle tracing which, if you’ve ever seen, you’ll realise how useless it is much of the time. (If you’ve not seen it before, be warned that you’ll get thousands of lines of very low-level junk for even a simple program.)

Why did he not talk about a tracing library, say, that logs trace messages into the database with a pipe? I ended up writing one myself, based on the information in the book but I’d preferred not to have!

I thought you said you liked it?

If you said that the last section was very negative I wouldn’t be able to disagree with you. However, this is a book that I’ve been using for over a year, not something I got as a review copy and skimmed. I’m still using the book on a daily basis so it must have some merit. I would never have found many of the problems if the book hadn’t been an important and useful reference for all this time.

O’Reilly know how to publish a good technical book. They focus on telling you what you need to know and how it does, should or, indeed, does not work. Feuerstein’s Oracle PL/SQL Programming is one of the better O’Reilly books, so you should be able to guess how highly I rate it.

I first got my copy over a year ago and I’ve spent most of that time on Oracle projects. I have kept this book by my side at all times and only on a few occasions has it not been able to answer my questions. It’s now so well used and grubby that I may be forced to buy a new copy.

The facts

Author: Steven Feuerstein with Bill Pribyl

Cost: $46.95

ISBN: 1-56592-335-9

Buy this book from Amazon.com or from Amazon.co.uk.