Pt 2

Which sort of brings me back to the point of the whole discussion. Software is written by programmers using a language, or languages to implement a given business goal. There are techniques that exist in order to help the programmer provide software in an accurate and timely fashion. OO is purported to one of them

But what I want to suggest is that you ditch the IDE of your chosen language and try to develop using notepad and the file-system. This is not because it’s some sort of purist ‘hark back to the mainframe’ days blurb; it’s because this is how you are going to learn about how good or bad the language really is. How difficult is it really going to be to manage hierarchies of classes without an IDE’s help? How difficult is going to be to maintain zillions of lines of code with just notepad and Explorer? How many more typo mistakes do you make without Intellisense, and AutoComplete? Is that the languages fault, or do you think you should learn to look at the screen whilst you’re typing instead of the keyboard?

When I first started to do this I realised a very fundamental point about programming languages. Programming languages are designed to implement a philosophy of development. I have no idea why I didn’t realise it before; perhaps it’s because I’ve never gone through the exercise before, or perhaps ostrich, my head, and sand came more into it.

On an evaluation of a language most people, of whom I am also guilty, assess syntax, and some semantics; I didn’t bother with the philosophy of the language, but its there for all too see. It’s there for all to assess.

The philosophy of the language seems firmly based on the development methodology. Some languages are procedural, some are OO, and some are something different. Yet most people pick the language, not the development methodology. I can choose C#, but really I’m choosing OO. I can choose C, but really I’m choosing procedural.

How many managers, or practitioners are actually aware of this strong, but subtle distinction? Do we know exactly what we are buying into? After all, you are buying into a technology, and methodology. You are choosing to follow a given path. You are setting your IT department down a road that, as long as enough time has passed, will be an irreversible choice.

OO, I believe, is the worst of the lot. It needs an IDE to help the human being manage its complexity. The consequence is that whether or not you are a complete OO expert, the chances are that you will have to learn a specific IDE in order to integrate with your new job.

With the IDE, of course, the complexity is hidden – which is, I’m afraid, just like VB6 and it’s COM underworld.. Am I being backward in this view? Probably, but hey, I still think it’s a valid opinion.

This aside, I think that there is a class of application that really benefits from the OO approach. I think that all things GUI-like benefit hugely from an OO approach. A textbox, for instance, will always be a textbox; will always be a vessel for some poor soul to type stuff into. It’s unlikely to change much.

Examples flood the OO textbooks. Examples that are ridden with hierarchical examples from the ‘real-world.’ Species taxonomy is one such example. Proponents claim that this models the real world – but really it models a human created model of the real world. There is a difference, and once again, it’s quite subtle. The real world does not classify its species quite like we, as humans, do. And fortunately, God does not like to shake things up in this arena too much, so one doesn’t need to worry about change too much.

I think that a lot of OO proponents are intelligent and articulate. Most of the ones I’ve met and worked with certainly are: to be an effective OO practitioner you need to be! It’s a shame that the vast majority of them do not stick around to suffer the consequences of change after the 2nd and 3rd development cycle. Anyone who’s been in the industry for more than five minutes will know that after change cycle 3, it’s time for a re-write with OO code. The code has become unmaintainable, and there’s no one left who really understood what the original design has become. The 3rd cycle normally comes in around year 5, which harks back to that wonderful marketing cycle the big companies adhere too.

I’m sure that there are marvellous counter examples that will ultimately trump what I’m saying. I am a consultant in London, and I would say that what I am saying is about 80% true for all of the companies I’ve worked for. It’s a sad state of affairs.

Do I have an answer to this? No, I do not.

In the vast majority of cases programming models are misused, or abused, because of a moment of necessity. Junior programmers are told to inherit this, override this, and general ‘get up to speed’ or ‘hit the ground running’ with no formal education in what it is that OO software is all about.

If you have a significantly complete specification then OO software can be a marvellous tool to distribute work across the development effort. But in the real world, it’s never the case. And when customers sign off on specifications that are incomplete or plainly wrong we fiscally punish them for being stupid.

Are they being stupid? We fine our customers for not telling us how to create our own objects. Is that right? I don’t think so. Would a functional language be the same? Probably, but there is case to presume changing libraries of functions is a lot less risky than changing interfaces, or object definitions. So much so, that I don’t think the process of invoicing, and arguing that the specification is a little short would be worth the effort.

That is, of course, if you have a design.

As with all programming methodologies if you have a design, you can apply your favourite technology or fad. If you don’t have a design, then OO is certainly not the way to go.

OO, and change? These two things don’t go together.