Object Orientation Pt 1

Why Object-Orientation Is No Silver Bullet

Many years ago in the software industry recognised that there was a growing crisis in the way that people designed, built, tested and maintained software. This problem was coined the ‘Software Crisis’ (not surprisingly!) and has been with us ever since.

This crisis lead the industry to adopt engineering principles in order to make their software more reliable – a concept that very few working programmers care about.

Here’s the essential modern problem: Software is expensive. Remember that. Yes, you can go and buy sophisticated anti-virus software for GBP 30.00, but if you want to write your own software to tackle the same job it’s going to take time. An awful lot of time. There is nothing easy about writing good or bad software – both are equally as difficult. Bad software is difficult to produce because bad software must still ‘appear’ to work. If it doesn’t then nobody’s going to buy it. Good software is an incredibly difficult thing to do, and I believe that it’s one of the hardest things that a human mind can apply itself to.

The essence of good and bad software implies that there must be right ways of doing things and wrong ways of doing things. This is not generally true of software. Sure, we can talk of IS09k but believe me – and I’ve worked under these regimes – it’s not good. In fact working under military standards is even worse. Unless that is you like signing forms, Microsoft Word, and are a better touch-typist than your bosses PA, of course.

The way software is developed is that a programmer will be asked to write some software. Most programmers have a very limited skill set (very true if you consider all possible ways to deliver a solution) so will choose the one in which they know best. The manager will, in his infinite wisdom, have produced a very detailed specification from which the programmer will develop his software and verify against for functional correctness. (Yeah right!) A few eons down the line the programmer will deliver his solution. Of course, in this context, programmer should often read ‘programmers’ as it is often the case that teams of programmers are needed to produce some of the simplest software about.

I’d like to take a closer look at the manager’s choice of programming environment. I know I said earlier that the programmer chooses, but that’s not really the case. The programmer was employed by the manager for the skill-set he has - specifically to fit an existing business need; it’s an extremely rare thing for a manager to predict future software trends and needs (and in many cases impossible)

It is also the case that any future training courses which will be chosen by the manager will most likely decide the outcome of what the programmer spends at least 1/3 of his working life doing.

So given that the manager has a very big responsibility for the careers of his fledgling programmers, and the even bigger responsibility for the future of his department and most likely the financial success (or otherwise) of the company he works for, how does the manager choose what is a good programming environment, and what is a bad one? I know beer and pizza make for an excellent programming environment but that’s not the environment I’m talking about. I’m talking programming languages, and styles of programming language.

Firstly we need to drop the IDE (Integrated Development Environment.) This is the pretty interface that (potentially) makes programming easier. The IDE has nothing to do with the effectiveness or otherwise of a programming language, the syntax, and the language architecture. So when I talk of languages you must try to imagine looking at them in notepad and divorcing that IDE. IDE’s, as every quiche eater knows, are pure evil ™

We need to digress just a little . . . what is a programmer? Well, I think that there are three types, which are the scientist, the developer, and the coder.

The scientist is the one who learnt how software should be correctly developed in university. He may have a PhD, has certainly got a Batchelor degree, and is possibly working towards his Masters degree. These people think they know best, will never change, and will become your manager. They should not be allowed to write source code.

The developer wears a tee-shirt and dirty jeans. Sometimes you can spot one in a company because these people refuse to shave and often have bits of yesterday’s lunch still in their beard. Their enthusiasm for sandals never ceases to amaze me. Never. A developer normally started life out as a coder, and has amassed vast numbers of years writing source code, architecting systems, and generally being a nice chap. They like to read books and learn new things. They are probably into mountaineering or other ‘let’s get back to nature’ style hobbies.

The coder is the guy who lives to write source code. When they’re not finishing their 80-hour office week they’re working on some new super shiny technique to recurse over the parse tree in that compiler that they’re writing. They only read books when stuff goes wrong. This guy’s hobby is his job.

In the real world most people who are involved in the production of software are a mix of all three of the above.

So what programming language will each type of programmer use? Probably the one that he was employed to use. The average time that a programmer in the UK is likely to stay in his job is around 4 years; a similar cycle is evident in the US; it’s funny that big corporations base their budgeting and especially marketing cycles around the same 4 – 5 year cycle.

Regardless, programming languages are ‘invented’ by scientists, not coders or developers who do the job on a day-to-day basis. These are the people, if you recall, who know best. They’ve done their doctorate and you can be sure as hell damn it they’re going to implement their ideas and force such ideas on the rest of us.

This view is extreme and I don’t necessarily subscribe to it. The reality of the situation is that that is what used to happen. Back in the ‘60s/’70’s and early ‘80s software languages were developed (with the exception of Ada which was developed by military committee) by computer scientists who believed that high level abstraction and strong typing were the key to the success of all software.

I beg to differ.

We’re now 20 years on, and we’re in a situation where even Microsoft and IBM have taken strong typing to it’s extreme (rather like Ada and other Pascal like languages) – but we still have a software crisis.

Even worse they’ve inherited (sorry: I couldn’t resist the pun) object oriented programming from the late 1960’s. For those who love it so much I can only say that there is a very good reason why no-one particular cared for 30 years about OOA, OOP, and other related acronyms.

In the first instance they’ve identified pointers as being the biggest evil of all programming and now only allow pointers as long as they’re marked ‘unsafe.’ So what the hell did they think went on before pointers were considered unsafe. How does commercial airlines have such an enviable element of safety with regard to its software systems? What about the nuclear industry before the advent of managed environments? What about rail or traffic control systems? What about salary systems? Is it such a miracle that you eventually got paid? (Purists will note that most salary systems in the 1980’s were developed in COBOL; I can only burst their bubble by informing them that the machine integration with their mainframe was mostly based on assembly, or C – which are both highly dependant on pointers) The point is, of course, that software has been around for a long time, and safety dependant systems do not, in general fail, and cause human harm.

Another point of the matter is that reliable, dependable software systems were and are available since and before the advent of the so-called strongly typed systems. Huge advances in software technology were made when people had access to the underlying architecture of the machine it was that they were manipulating and not by some academic abstraction.

To my sadness, programming is now the application of logic. Any art, any cunningness relating the manipulation of a machine has now disappeared. It’s about writing any old tosh and relying on some ‘marketing genius software company’ to pick the bones out of the mess you’ve just written; this act of course, is called compiling.

Sure you can devise excellent software using modern techniques: but inevitably these are much more expensive than what they used to be – and require much bigger teams to derive a success.

So I ask - what advantage has been achieved implementing object-oriented techniques. Well, firstly, it has to be understood that OO is an interface to the human programmer, and not to the machine. Machine architecture has a long way to go before it understands polymorphism or anything else relating to OO. There is that modicom of testing that most people call a compiler, but that’s not enough for the machines – but it is often enough for the programmer to accept that it’s compiled (as if compiling even constitutes the first 1% of testing that needs to occur to guarantee reliable systems)

OO is about making it more logical, more understandable to a human being. It is a long way from an assembly script that describes in detail what it is that the human designer wants the machine to do.

It’s so far removed, in fact, that college graduates no longer understand that computer programming is actually about moving data around. You move data to the display buffer (and something else works out how to display) You move data in and out of RAM and in and out of a hard drive. Data arrives from the mouse and the keyboard. The vast majority of assembly instructions are about moving data. The last estimate I saw was that 68% of assembly instructions on a completed system were MOV: the one’s I’ve looked at (on my machine) come in more like 80%.

Even worse OO programming doesn’t describe how classes should communicate – or how they should move their data around. This behaviour is by design, of course, as it violates encapsulation – it’s up to a client to ask a server for the information, a class can never publish it’s internals (so instead of publishing the internal structure of a class you need to iterate through it’s properties – yeah! I’m sure it’s more readable to a college goon, but it’s much more inefficient than passing a long pointer) There are, of course, wonderful design patterns that address this issue (apart from the inefficiencies)

OO, whether you like it or not, is one abstraction too far.

Pt2 coming soon . . . .(everything these days is a trilogy, right?)

I agree with you up to a point. If we didn't have SOME kind of a standard or direction, how would anything interop? We would have hundreds of different companies doing their own things and each computer would have to accomodate for each one.

Ecspecially with this transition towards building "web solutions" instead of desktop applications, the world would be in chaos. Everytime you went to a website, you would have to download that companies run-time engine to be able to view their page (we can't just regress to a world of nothing but html).

While I agree that on one extreme (like adding "common" to intellesense to keep people from getting lost and saying "hmm, wonder what that does?" from time to time), IDEs are over friendly and way too easy. But on the other extreme, where do we say "ok, this is abstract enough to be used universally, but defined enough to interoperate without issue."

am i actually suppposed to read that?

Very nice rant - I like it!

(but I must say that VS 2005 IDE has a neat feature... Add a parameter to a function - this invalidates all the places it's called - but all those "error lines" appear in a window that you can "double" click on to visit each one for fixing - stuff like that makes the programmer/coder/developer/hack more productive)

Quote:

---

Originally Posted by fahad k

am i actually suppposed to read that?

---

I don't care if you do.

I have ranted about OO for years around here: I owe it to those who've been on the short end of the rants to justify what I've said properly.

This is part 1, part 2, and 3 are on the way . . .

I will publish the full essay (aka Rant) in a few weeks, here!! Perhaps the mods would consider an essay/rant area?

Quote:

---

Originally Posted by szlamany

Very nice rant - I like it!

(but I must say that VS 2005 IDE has a neat feature... Add a parameter to a function - this invalidates all the places it's called - but all those "error lines" appear in a window that you can "double" click on to visit each one for fixing - stuff like that makes the programmer/coder/developer/hack more productive)

---

I haven't actually got to M$ OO implementation; that'll be in Pt3!

Quote:

---

Originally Posted by yrwyddfa

OO, whether you like it or not, is one abstraction too far.

---

Well done for the marathon rant. I must admit that my feeble OOP-loving brain has not the faculties to susttain sufficient interest to read the whole...uh thingy, whatever.

[non-confrontational]How much OOP have you done?[/non-confrontational]

Quote:

---

Originally Posted by yrwyddfa

I will publish the full essay (aka Rant) in a few weeks, here!! Perhaps the mods would consider an essay/rant area?

---

At least that will keep you outta the world events forum for a while!

Quote:

---

Originally Posted by wossname

[non-confrontational]How much OOP have you done?[/non-confrontational]

---

That's an oxymoron with yrwyddfa :D

Quote:

---

Originally Posted by wossname

[non-confrontational]How much OOP have you done?[/non-confrontational]

---

On and off, really. Loads of C++ rubbish, loads of smalltalk, and Object C. Started C# recently.

And of course interface-based OO in VB6.

For a 31 year old, I've been around the block a few times: my bald head is a sure testament, believe me!

Quote:

---

Originally Posted by szlamany

That's an oxymoron with yrwyddfa :D

---

Would that be the OO, or the non-confrontational bit? :)

I see.

Quote:

---

Originally Posted by yrwyddfa

Would that be the OO, or the non-confrontational bit? :)

---

The non-confrontational bit!

Quote:

---

Originally Posted by wossname

I see.

---

Eclectic as it gets, I guess.

I must congratulate you with your adoption of C# though. I would have been most dismayed had you selected VB.net as your tool of choice. Although it would have given me ample ammunition to harrangue you with for months, nay years to come. :D

Good call.

Quote:

---

Originally Posted by wossname

I must congratulate you with your adoption of C# though. I would have been most dismayed had you selected VB.net as your tool of choice. Although it would have given me ample ammunition to harrangue you with for months, nay years to come. :D

Good call.

---

Market forces, my dear boy, market forces. :)

I can philosphise and moan, and rant as much as I want. I know I won't change anyone's opinion, and I too, will succumb to that joy which is market forces. :(

I have, of course, a wife, and four kiddies to care for :)

Quote:

---

Originally Posted by szlamany

The non-confrontational bit!

---

I know I can be contrarian sometimes, but not confrontational, surely?

Quote:

---

Originally Posted by yrwyddfa

Market forces, my dear boy, market forces. :)

I can philosphise and moan, and rant as much as I want. I know I won't change anyone's opinion, and I too, will succumb to that joy which is market forces. :(

I have, of course, a wife, and four kiddies to care for :)

---

Ohhhhhhhhhhhh.

I'm sorry, in your marriage license if you read the small print you will see that it says "I hereby give up my geekdom and I shall no longer harp on about OO Programming. Especially on VBF. By order."

:D

Quote:

---

Originally Posted by wossname

I shall no longer harp on about OO Programming.

---

You sound frightened ;)

Quote:

---

Originally Posted by yrwyddfa

I know I can be contrarian sometimes, but not confrontational, surely?

---

No I meant that I'm confrontational, you jerk. If you don't like it then you know where you can shove it, OK! :mad:












:D :lol:

Well of to the pub to lean up against the bar and reason objectively about this that and the other.

Speak to you all when I'm pissed, then (about 11:30pm)

Quote:

---

Originally Posted by wossname

No I meant that I'm confrontational, you jerk. If you don't like it then you know where you can shove it, OK! :mad:












:D :lol:

---

Meet me outside the pub at 11:30 and we'll solve it all with pistols at twenty paces, then :p

Lightweight. I'm still pissed from Christmas (2004).

Interesting rant, from a 'Let me step back and look at it' point of view. The general theme of it seems to be that you feel something is being lost with modern programming.. Perhaps that the "art" of programming has been replaced with the more utilitarian "science" of programming?

Was it truly the "PhD's" that developed the object model? What was their motivation for doing so, to simply be "right"? I would imagine, that like any other profession, that they thought it could be done better. Myself, I like the oop. I can definately understand why others do not. But what motivates someone to say "You know, I could do this in a universal way that everyone understands, and allow my code to be used by others, and allow others to write interface based blocks of program that I can in turn use." ? Is it a need to be a know-it-all, a need for recognition, or a want to do it better, for whatever reason? Was there profit in the concept of OOP?

As for the effect of it's implementation, I leave that to a matter of opinion. I am not saying we should always praise efforts regardless of their fruits, but it does seem like you ignore the positive aspects of OOP in your essay/rant.

As far as the IDE being pure evil, I completely disagree. To use the last line of acceptable arguing of my point, I will bust out "An Analogy." (which is therefor not necesary to accept ;))

I can use a rounded chisel, and carve, to the best of my ability, fancy scrollwork on the edge of a dining room table. I can also use a router and do similar work that looks clean, is perfectly aligned, and beautiful. I just need the right bit and a knowledge of proper router use. Now, my router can't carve a unique pattern on the leg of the table, or perform intricate scroll work, but it's not supposed to. It's supposed to crank out something clean, fast, and to a certain specification. Like the IDE vs assembler programming, they are completely different tools, for completely different purposes. It is only when you equate their functionality, that you can argue the down sides of the IDE. If it is thought of, and used as what it is, a Rapid Design tool, it is a fantastic product.

Bill

I was never too fond of OOP or .NET for that matter. OO is truly pure evil. Good essay. :thumb:

Very nice piece. I can move it to the General Developer forum if you like - then I will rate you ;).

I have often thought about the actual benefits of OOP and whether those who swear by it are totally insane. The fact that its existence is entirely for the benefit of the human mind means that whenever using OO, the programmer should be thinking in real world terms; personal experience has taught me that if you start thinking about it in computer speak you will get in a horrible mess.

I have the unusual benefit of being at college at the same time as working for a multi national company. The functional "hubs" of the company exist in the US, UK and Germany and the onslaught of Quality Assurance, Best Practice, Project Planning, etc., etc. Has served none other than to distance these three hubs further than they already are.

In fact, the reason I work for them is because of the inability of the folks in the US to communicate properly with us in the UK. The result, the US has a wonderful web based ordering system, which, the UK cannot use because they were so wrapped up in the finding the correct approach to the design of the system that they failed completely in capturing our requirements. I am now responsible for a UK version of the site which has a vastly reduced subset of features compared to the US site.

Since working their I have learnt that a successful project, isn’t about following standards to the word; it is whether or not the out put works properly and what I am learning at university contradicts completely, what I see in the real world.

Our department happens to the most successful in the company; where other departments are spending 80% of their time trying to improve what is already working well to make it work better, we get on with what we have got and make do.

Personally, I think OOP is a useful tool, provided it is used sensibly. Anyone who believes it is the answer to all coding problems is a fool. One of the areas I feel OOP has huge benefits is in web development. Web development is one of those areas which actually requires a higher level of abstraction and, as the web already relies wholly on standards, OOP fits well into the equation.

Quote:

---

Originally Posted by Jacob Roman

I was never too fond of OOP or .NET for that matter. OO is truly pure evil. Good essay. :thumb:

---

Yeah, why any one would want an understandable and easy to use interface to the most used windows OS apis. I for one shun a logically laid out library of usefull and reuseable code that I didn't have to write.

ok to those who long for the days of yore. Get a grip on reality. This reminds me of an old timer I worked with who used to always say "Those old mainframes we used to work with never crashed like these new servers do." my typical response would be similar too.. "Hey saggy nutts, go ahead and try to serve up something like google maps on an IBM 8100 and let me know how that works for you".

The programing world has evolved out of necessity. apps are constantly getting more and more complex at a blinding rate. Why rewrite old code? Go ahead and waste your time doing it and you will never be able to release anything cutting edge.

This wasnt a rant at you JR. I was just commenting on the anti .net oop progress topic. :wave:

OO lets stupid people be programmers.

oi!

I haven't finished this piece yet. Pt2, and Pt3 are on their way . . .

Read Part 2

yrwyddfa, how many other developers do you work with on a daily basis other than yourself? I find it very difficult to believe that you can work on a multi man dev team, say(5+), that is building the same product without using OOP and remain profitable.
OOP has made it simple to move human resources around to different areas of an application as needed. The nice thing about OOP designed apps is that no one has to own one particular area of code. If a resource gets moved to an unfamiliar area of an app at least he can begin working quickly. That sure beats having to read code line by line for possibly weeks just to figure out what is going on.
Take a situation of a 25 man dev shop. the dev shop has 5 applications currently under development. the actual coding time for each app is bid at 30,000 man hours. Keep in mind unpredictable breaks in action in the dev cycle that will happen during every app. If you would like examples I can fill vbf's disk arrays with them if you like. Using your method, you would have to assign 5 devs to each application permanantly. During breaks in action, that entire 5 man dev team is useless to you. Now, using an OOP design, you are not nailing down devs into a box and can eaisally move them inbetween apps. Say Project A has a week of down time. You move them to project B. Project B now has 10 (instantly productive) devs. Project B now finishes early(Calendar hours) freeing up 5 resourcess to start a new project or finish project A early. That frees up 10 devs ahead of schedule. That is where the money is made.

Quote:

---

Originally Posted by MasterBlaster

yrwyddfa, how many other developers do you work with on a daily basis other than yourself? I find it very difficult to believe that you can work on a multi man dev team, say(5+), that is building the same product without using OOP and remain profitable.
OOP has made it simple to move human resources around to different areas of an application as needed. The nice thing about OOP designed apps is that no one has to own one particular area of code. If a resource gets moved to an unfamiliar area of an app at least he can begin working quickly. That sure beats having to read code line by line for possibly weeks just to figure out what is going on.
Take a situation of a 25 man dev shop. the dev shop has 5 applications currently under development. the actual coding time for each app is bid at 30,000 man hours. Keep in mind unpredictable breaks in action in the dev cycle that will happen during every app. If you would like examples I can fill vbf's disk arrays with them if you like. Using your method, you would have to assign 5 devs to each application permanantly. During breaks in action, that entire 5 man dev team is useless to you. Now, using an OOP design, you are not nailing down devs into a box and can eaisally move them inbetween apps. Say Project A has a week of down time. You move them to project B. Project B now has 10 (instantly productive) devs. Project B now finishes 1 calendar week early freeing up 5 resourcess to start a new project or finish project A early. That frees up 10 devs ahead of schedule. That is where the money is made.

---

My goodness me.

I haven't given out a 'better' method. I don't purport (at least not publicly) to have a better method. And would I share it with you, even if I wanted to? Doubtful.

I've managed teams of around 30 developers in non-OO fashion. I delivered it ahead of schedule and under budget, so I think your worries are a little unwarranted.

If you believe that OO is the answer to management fallabilities, rather than programmer productivity, then I think that you are wrong.

Again, it's only an opinion, and I'm totally open to be shown that my ideas are completely out of the ball park.

Quote:

---

Originally Posted by yrwyddfa

My goodness me.

I haven't given out a 'better' method. I don't purport (at least not publicly) to have a better method. And would I share it with you, even if I wanted to? Doubtful.

---

I know you haven't. That's why I asked LOL. Glad to know you would be willing to share it with me if you did. :rolleyes: Understandable considering its a multi billion dollar industry. I wouldn't want to rip off your IP. We all know that never happens in our industry.

Quote:

---

I've managed teams of around 30 developers in non-OO fashion. I delivered it ahead of schedule and under budget, so I think your worries are a little unwarranted.

If you believe that OO is the answer to management fallabilities, rather than programmer productivity, then I think that you are wrong.

---

Managing fallabibities? I'm not talking about management. I'm talking about competing with shrinking budgets. That is a worry that is warranted if you want to make money and stay sane in the process. That hits my pocketbook as well as managements. I firmly believe that oop increases programmer productivity making management less involved in the stuff they know nothing about Like writing apps and more involved in juggling resources.<-- that is a whole different rant that I am sure we are 80% in agreement over.

I would rather have my manager give me 5 resources and hit the ground running rather than getting 5 resources and saying "sheit, resources 1 2 and 3 have to spend 2 man weeks of billable time figuring out What the hell is going on."

Quote:

---

Again, it's only an opinion, and I'm totally open to be shown that my ideas are completely out of the ball park.

---

Other than that, your ideas seem valid to me. of course without a good method of implemtation in a human development environment all you are selling is a car with no steering wheel.

Quote:

---

Originally Posted by MasterBlaster

I know you haven't. That's why I asked LOL. Glad to know you would be willing to share it with me if you did. :rolleyes: Understandable considering its a multi billion dollar industry. I wouldn't want to rip off your IP. We all know that never happens in our industry.


Managing fallabibities? I'm not talking about management. I'm talking about competing with shrinking budgets. That is a worry that is warranted if you want to make money and stay sane in the process. That hits my pocketbook as well as managements. I firmly believe that oop increases programmer productivity making management less involved in the stuff they know nothing about Like writing apps and more involved in juggling resources.<-- that is a whole different rant that I am sure we are 80% in agreement over.

I would rather have my manager give me 5 resources and hit the ground running rather than getting 5 resources and saying "sheit, resources 1 2 and 3 have to spend 2 man weeks of billable time figuring out What the hell is going on."



Other than that, your ideas seem valid to me. of course without a good method of implemtation in a human development environment all you are selling is a car with no steering wheel.

---

I am selling nothing. All I've done is present ideas: I don't expect you or anyone else to agree or otherwise with them.

I posted my ideas (with full knowledge of the blasting I'd get) with respect to the good people I've given a hard time in the past.

That's it.

Nothing more, nothing less.

I started programming in an odd place: Quattro Pro macro language.

Now, this language had a few limitations, to be sure, but it did have one interesting feature in that any significant project ended up with code that looked a fair amount like ASM with a nearly infinite number of registers.

Much of the code was along the lines of Move CellX to CellY, Move theaddressof CellY to CellZ, get the value referenced by the address in CellZ, etc.

One thing this taught me was how terribly hard it was to write complex code in ASM. Any small piece could be fine and efficient (ok, nothing was efficient about that language, but a similar constuct in ASM would have been efficient), but once projects reached a certain size, the whole thing turned to spaghetti, and maintenance became a total nightmare. One of the key reasons for this was that, while you could write ASM like code, you couldn't really comment anything. A good rule of thumb for ASM that I have heard is one line of comment for each line of code. The ratio in Quattro Pro was 0:1 rather than 1:1. Not goog.

The point of all this is that I learned that there is a level of complexity the human mind can keep track of at one time, and once you exceed that, you need an organized system to manage the complexity for you. OO is just one attempt at such a system, as is block structured languages. You can use either well, or you can use either poorly. If you do the latter, it really doesn't matter what technique you use.