Submit Your Article
Marc Funaro kicked off quite a heated debate on his blog lately by raging against people pushing object-oriented programing/design and how his attempt to follow their advice nearly led to the collapse of his business. Marc was expressing a common frustration that many of us have heard from people who try to learn OO, especially from people with a long history of procedural programming and/or no computer science background.
I’ve left comments on a few of the blog posts but several people have asked me to go into a bit more depth about my thoughts on this issue (since I’m one of the people sometimes accused of “pushing” OO and insisting it’s the “right” way to do things).
First off, I’ll repeat what I’ve said many times: there is no One True Way. What works for me might not work for you and even I will solve the same problem different ways at different times in different circumstances.
Having said that, for me there is almost no problem today where a purely procedural solution is the right one for me. Years ago, that wasn’t the case. Prior to 1992, I hadn’t worked with any OO languages but I hadn’t done just procedural programming either: I had started learning functional programming techniques around 1982. As part of my university degree, I did a one year work experience assignment at an insurance company, mostly writing IBM 8100 assembler (and some COBOL). I helped design and implement a number of powerful library routines for a hierarchical database system the team was developing, recursive routines that I now recognize as implementing the Visitor design pattern (which I hadn’t heard of at the time). What I’d learned from high-level functional programming changed how I wrote the most procedural language available – assembler.
In 1992, I started to pick up C++. I picked up Smalltalk in the mid-90’s. By 1997, I’d discovered Java. Over the years, I got a little better at writing OO code and started learning about design patterns and OO design. It was a process, a journey, still ongoing. Along the way there were a few lightbulb moments and there was plenty of frustration.
Surprised? Knowing what you know of me from my blog and my posts on mailing lists and my talks at conferences, would you expect that I have been through a lot of frustration trying to become a better software developer, a better software architect?
I’d be surprised at anyone who had not had such frustrations!
Why do we go through this? Why do we push through to the other side to learn – and master – this stuff? IT is an interesting industry because not only does it change – like all other industries – but the pace of change is extremely fast. What we learned last year will be outdated next year, or the year after. If you look at job descriptions for ColdFusion developers, they’ve changed over the last few years. Most of them want experience with frameworks and CFCs now. As Matt Woodward said in comments on those blog posts, the debate is over – OO won. Years ago.
No matter what you think about OO, the industry has moved on and OO is the norm. COBOL, the mainstay of procedural programming, adopted OO features in the early 90’s and OO COBOL compilers were available by 1997 with an OO ANSI standard following in 2002. Ada was the first ANSI standardized OO language in 1995. C++ became an ANSI standard in 1998 but work first began on that language in 1979. Simula is considered the first object-oriented language and it appeared in 1967. Smalltalk appeared in the 70’s, became a de facto standard in 1980 and an ANSI standard in 1998. All modern languages – all new languages – embrace objects from the start. Many modern languages go beyond OO and incorporate other advanced features – some of those languages would probably seem incomprehensible to traditional, procedural programmers. We shouldn’t expect to understand everything but we should expect to continually learn new things so that we remain employable, relevant, interesting.
One of the subjects that came up in the various blog conversations was Fusebox. Someone lamented that “even” Fusebox had become OO. Fusebox is a very important illustration for the CF community. Fusebox 4 was built as four large, procedural files and supported both procedural and OO styles of application (yes, a framework written in a procedural style supported OO – even Fusebox 3 supported OO application development!). Fusebox had become hard to maintain and enhance. In order to move forward, I rewrote the core files to be more maintainable – I rebuilt Fusebox as a set of collaborating objects but it was 100% backward compatible. The same procedural apps that ran on Fusebox 4 still ran on Fusebox 5. The same OO apps that ran on Fusebox 4 also still ran on Fusebox 5. Even tho’ the core files changed from pure procedural (and unmaintainable) code to fully object-oriented (and, hopefully, more maintainable) code, the range of supported application styles did not change.
So, how do I really feel about Marc’s post? I sympathize. I know his frustration is real. His background is design and not computer science – of course he finds OO to be extremely hard. I have met only a handful of people who have a natural ability for OO thinking. Sorry, but for everyone else, this is hard shit! There are no short cuts. Some years ago, I gave a talk at CFUnited (I don’t even remember which talk now) and a guy came up to me afterward and asked me about learning OO. I told him to go easy on himself and expect this to be a difficult path that would take him a long time to learn. He exploded in anger, accusing me of calling him too stupid to learn OO. For me, that perfectly sums up the unrealistic expectation many people have about learning OO. It is hard. It does take a good long while. Many people give up. Some people push through and eventually reap the benefits of the pain of learning this stuff – and of making lots of mistakes along the way.
Don’t beat yourself up if OO doesn’t make sense. Don’t kill yourself trying to master it. I don’t “get” numbers but many people do (including my wife). I completely “get” abstract math (my wife does not). She “gets” OO but she can’t program (programming languages are too fussy for her tastes). Don’t kill your business attempting to achieve some ideal that doesn’t work for you. Spend some personal time on it, sure, but don’t lose too much sleep over it.
Here are the original blog posts:
- Marc Funaro’s original post
- Steve Bryant’s response
- Brian Rinaldi’s different slant
- Scott Stroz’ challenge
- Brian Kotek – it’s not OO, it’s people
- Peter Farrell on learning OO
Topics: Application Development, ColdFusion, Database, Java, Programming
