Unless you live in a cave, you know that in the last few days another Object Oriented (OO) vs. procedural debate has flared up. I thought this would be a great opportunity to discuss an attitude I have seen from some developers that mirrors the attitude I saw in quite a few people in my previous career.
For those who do not know, before becoming a developer, I spent 14 years as a paramedic. One similarity I have noticed between my former and current careers is that you can never know enough. There is always something new you can learn to make you better at your job. Another similarity is that if you ever stop learning, well, then the job has passed you by.
I found that the best medics are the ones who would critique a call when it was done and try to find where they could have performed better and work on improving those skills. I would like to think I was one of those medics. Regardless of the outcome of the call, I always found at least one area where I did not preform as well as I may have wanted. Its easy to look at the patient outcome as the sole indicator of how the call went, but rarely was that a true portrayal of how the call went.
I have also found that the best developers are the ones who critique a project when it was done and try to find where they could have performed better and work on improving those skills. I would like to think I am one of those developers. Regardless of the outcome of the project, I always found at least one area where I did not preform as well as I may have wanted. Its easy to look at the project outcome as the sole indicator of how the project went, but rarely is that a true portrayal of how the project went.
When I was medic, I always wanted to learn more. I always wanted to do what I could to become a better medic. As a developer, I always want to learn more. I always want to do what I can to become a better developer.
For me, becoming a better developer means learning new ways to solve problems. Whether this was from learning (or continuing to learn) OO, learning how to use frameworks or even new technologies (such as Flex) I gained new tools I could use to solve problems. Sometimes, what I learned is that, for me, the new tool might not be such a great fit, but, I still learned something.
With each new tool I can add to my toolbox, the better I can become as a developer and, more importantly, the more valuable I become as a developer. I say ‘become’ in that sentence is because just having the tool does not make you better, you need to consider these new tools and learn when is the best time to use them. A carpenter can have every tool under the sun, but if all he ever uses is a hammer, without considering using any of his other tools, he’s not going to be a very good carpenter. Another way of saying this is, if all you know how to use is a hammer, everything looks like a nail.
While I have never been one to shy away from learning new stuff, recently my desire to learn new stuff has not been as fierce as I would like. That changes today. I am issuing a challenge. A challenge to become a better developer. A challenge to everyone reading this, myself included, to pick a new tool – be it a new application framework, new concept (such as OO), new process (such as unit testing or using code repositories such as SVN or Git) or a new technology (such as Flex or Groovy) – and sit down and learn how and when to use it. Learn the advantages you gain and any possible negative effects of using this tool. Then keep the tool in your toolbox until the time comes that you need to use it. Finally, when you feel comfortable with that tool, go pick another one and start the process all over again.
I challenge you to become a better developer and not let the job pass you by.
DougHughes.net 
Comments on: "Throwing Down the Guantlet" (7)
Scott,
Great article – and I couldn’t agree more. I try to make it a goal to learn at least one new tool/concept/framework/etc every couple of months – and I have accumulated a vast array of things that I can now use to solve problems.
LikeLike
Well, as some feedback to improve future blog entries, I think it would be useful to link to some of the blog posts that are causing the OO vs procedural furore, as the debate has gone under my radar!
(Presumably it’s on blogs that don’t show up in my feed?)
The other thing is that learning is about expanding your range of techniques – I’ve been using computers since the early 80s and working in IT since the early 90s, and the more experience I have, the less inclined I am to take arguments on their face value.
OO has a lot of strengths – and it’s taken decades for a lot of the ideas of Smalltalk to have filtered down into mainstream development languages – but the problem is for a lot of developers it’s the only game in town.
Next thing you know they’re talking about the object-relational mismatch (and of course how relational databases are wrong, rather than different), or making design decisions to avoid having to deal with SQL.a
They’re all just items in your toolkit – functional programming, OO, procedural, relational databases, object stores – and I think the key is getting to the point of choosing the right one for the job, rather than ‘believing’ in one over the other. Computer Science rather than Computer Religion.
LikeLike
Wise words – As a contractor I move in and out of OO and procedural setups and each new client adds a new spin on the frameworks available. I have been in the business now for 9 Years and I am still learning nw things on a week by week basis with ColdFusion and also SQL Server. I have not used Flex commercially but I have looked it up and followed the training and my ‘toolbox’ has grown. I can now advise my clients if I think a flex application will serve their purposes or not. No matter how ‘educated’ you are there is always something new to learn. Thank you for the inspiration.
LikeLike
I have resisted learning a framework for a long time siting reasons such as…
“This project is not big enough to justify a framework”
or
“I’ve actually managed projects in the past where the framework slowed the application down to a crawl once it was converted to the framework”
At any rate, I think that I write smart, solid code but I also think that it could be better managed by using a framework so my goal after reading your post is to learn and use at least one framework before the end of this year.
Thanks for helping me decide to get off my ass.
LikeLike
@Jules the blog post that started the particular debate that Scott mentions here is…
http://www.advantexllc.com/blog/post.cfm/how-oo-almost-destroyed-my-business
There are many words of wisdom in Scott’s piece here and that blog post and its comments. My feelings, for what it is worth are…Clients and users mostly do not mandate how we structure an application, They care first about its functionality then about its stability and scalability and sometimes its longevity. I have seen/tested many 100’s of ColdFusion-JRun applications and blogged about that here and on my own blog http://www.cfwhisperer.com. Those applications heavily vested in CFC based frameworks have proven to perform worse than those not heavily vested in CFC based frameworks, that is my experience, so far.
LikeLike
I am staring to feel like that bloke in ‘The Fast Show’, Dave I think, who agrees with the person currently talking and then when 2 people come together and start to argue with each other he is playing agreement tennis. Mike makes the best point here though. The client does not care how you code his website. He just wants it to be available 24/7, be fast and fit for purpose. He wants it to bring in custom and therefore be easy to navigate (to the shopping cart usually). So while we can argue until we are red in the face it does not really matter how you code it as long as the above is met. As long as the client gets what they want.
The decision of whether to use OO or procedural can depend on your working environment. Do you care whether or not the code you hand to your client can be maintained in 2 years time? Do you care whether your team members (if thats your setup) can understand what you have written? Can you understand what you have written? Is it easy to add a new function to your application such as a shopping cart of a forum? Do you support Manchester United or Manchester City? Your client does not care, he or she probably does not understand a word you say (programmers are from Mars after all).
So, if you code procedurally and all is well, continue doing so. If you code using OO and all is well, carry on. If your organisation is using OO and you are not then you have a problem. Can you convince your boss that the way you do things is better? You will need to substantiate what you are saying with cold hard facts, but how can you do that unless you know both methods. Spend a little of you spare time creating an identical website in each method on the same server and get back to me with the results, I challenge you.
LikeLike
Thanks Mike – read it all now – it actually seems to me that the problem is as much about frameworks and a certain approach to software engineering and Java as it is about OO.
I do think it’s good for developers to understand OO properly (which to my mind probably means starting with a proper OO language THEN learning Java and why it needs dependency-injection frameworks – which a lot of the time are Java problems).
It’s interesting to compare something like Seaside with your typical Java web framework, for instance, or play with something like Nodebox (Python) or Shoes (Ruby) without necessarily deciding you need to become a Rails developer.
It’s also notable within the OO language community that there have been an explosion of ‘simple tools for simple problem sets’ (Rails, Django, Camping, and Java equivalents like Grails).
What’s sort of happened is that the discipline of Java development has become like people who design and build skyscrapers, rather than houses. It’s all architecture and construction, and there are similarities and places where one can learn from the other, but the scale of the problem is different.
And the debates are often absolute – Rails is bad because . . . rather than talking about what things are / are not suited to.
LikeLike