Back to Thoughts On Technology Page | Back to Peter's Home Page | Back to Family Home Page
Basic Study Path for Object Oriented Software Engineering
Peter Rose - 07/2009
Okay, I've been doing software engineering now for over 25 years specializing in the analysis, design and coding of business applications, and from 2000 through current writing date of 2009: web based Java J2EE apps. Here's the thing, it never ceases to amaze me that code others have written that I have had to work with is so poorly structured. There's no other way to say it. It's not a nice thing to say, but then it's not a real demonstration on the part of other programmers - senior level; not just beginners - of their understanding of how they should be doing the job they are being paid a lot of money to do. This all may be a little harsh at first, but bear with me as I rant, as I will offer good news and hope... later.
My son is an certified Honda auto technician and knows full well that regardless of how good he repairs someone's car, if that car just 'runs' but still makes noises or belches smoke out of the tailpipes, he's just not going to have a job for long. And he's seen mechanics fired for doing stupid stuff, like leaving a couple lug nuts off, regardless of if the wheel would have stayed on or not. When a job is done badly, there is little sympathy for the mechanic.
And so I ask myself why I should have sympathy for a programmer who fails in the most elementary of object oriented best practices coding. I shouldn't and I don't.
I worked hard to be good at what I do; still do, still study and evaluate what I'm doing. Our career is that of a professional, not semi-skilled physical labor. If you expect to be paid and treated as a professional then you had better work and study and demonstrate professional attitude or you will finish out this life with little to be proud of; just a fistful of money that you conned unwitting non-technical managers out of.
Now, don't get me wrong here. I am not the best developer in the world. Nor am I the smartest software engineer. I'm just an ordinary developer as far as my skills and smarts go, but I have passion to do it right. My code is not fancy, nor do I know all the 'stuff' I probably should. In fact, I have little ability out of my chosen expertise with little awareness of setting up web servers, or doing low level systems programming, or building framework utilities and tools. I'm a specialist that uses these tools to write my code. And that code is as good but as absolutely simple as it can be. No one has a problem understanding or modifying my code. No one. That's how good my code is designed and written.
And by the above, I am not implying that everyone but me is stupid that can't produce good code. I have worked with brilliant people that code around me like the toilet water swirling around in the bowl; they are so good, it just makes my head hurt thinking about it. But you know what, that doesn't make their applications good. They are so smart that their code is so complex that poor folks like me have to really struggle with it. To me, that's not good coding. It's not good because it's complex.
Oh, sure, complex things are just a collection of simple things. That's the theory, right? Well, that's true if the logic used to create those simple things is in itself simple. I'll give an example that I was faced with just a few years ago when our group was going over the code of another group that was interfacing their code with ours. It was brilliant, but no one at the table, other than the architect, could easily see how it was structured. It was designed with a series of nested patterns and elegant facades that was as tight and compact and efficient as it could possibly be.
But none of us had the slightest clue as to how we could go about enhancing that code and integrating it into what we were doing. Though raising the extreme ire of our project manager who was present at the meeting, I objected to this code and explained why. The architect, who was one of the most brilliant but level headed guys I have ever had the fortune to learn from (Aslak Hellesøy), agreed with me, and the other group was ordered to re-design and re-write the entire module.
This sent the manager's blood pressure over 200 and unfortunately put me in the dim-light in their eyes from that point on. But hey, the code was not right. It should have been right because the programmers should have known better. The project we were on was extremly complex and would be controlling the flow of literally billions of dollars of product. This is not the place for mediocre - or fancy - programming.
Look, this is not rocket science, either. I've already admitted to you that I'm probably not even as smart as you are. So, why do I continue to run into code that looks like it was written by a high school kid 20 years ago who only knew the brain dump method of linear, waterfall programming? I programmed like that when I was in college in 1970 writing brain dump FORTRAN. But this is 2009! Folks have been writing commercial (vs academic Lisp) object oriented software since the early 1990's. And yet, a programmer thinks that because they know every conceivable language-de-jour API call that they can then write an acceptable application.
Sorry, but that's just not going to cut it. Not with me, anyway. Not when you're getting paid a lot of money to do it right for the business, rather than just getting the assignment done so you look good to the manager. "Hey, it works, doesn't it? What more do you want?" Actually, that is a pretty poor excuse for doing something that would get you two weeks check and a road map in any other profession.
Okay, that's all the "tough love" I have right now. It's broken, so how do you fix it? When I started learning Java in 1997 and undertook a formal study of Object Oriented Analysis and Design (though I had begun to muddle around in this stuff with PowerBuilder a couple of years before), it was a tough go. I had to change the way that I thought about problem solution in order to learn how to apply the principles of design analysis into my coding practice.
You can do this as well. And it's pretty simple, particularly if you are an experienced developer. You just have to have an open mind about this stuff, because you do have to look at things in a different light.
But where to begin.... That is a problem because there is so much information out there and so many different approaches. The purpose of this article, other than grinding your ego into the ground, is to provide you with a bare bones framework of study to at least show you what's involved. But it's up to you to actually apply it. You can't just read about this stuff and get it, no matter your intellect - or, as in my case: just being a normal hard working developer looking to do it right.
May I humbly suggest you begin this process with a review of some of the articles on this site that I have written as an overview to a more detailed study that I will outline for you next. The reason I point at my writing first is because it summarizes many of the really bad coding potholes I have seen in applications code and how one goes about resolving the issue. Give a look and see what you think:
Okay, here's that reading list presented in a reasonable order of attack:
Case Studies in Object-Oriented Analysis and Design by Edward Yourdon, Carl A. Argila. I took a course in OOAD in Boston, MA from Dr. Argila in the summer of 1996. The book covers the analysis and design of two complete object oriented applications: a small magazine subscription application for the applications view, and an elevator control system for the systems view.
Java Design by Peter Coad. A guide introducing design with Java, incorporating two ongoing design examples. Coverage includes interfaces, composition, threads, and notification. It discusses strategic issues associated with Client/Server development projects and identifies projects where Java would be an ideal language to use. The book is heavily illustrated with a full case study throughout the book.
Refactoring: Improving the Design of Existing Code by Martin Fowler. Besides an introduction to refactoring, this handbook provides a catalog of dozens of tips for improving code. The best thing about Refactoring is its remarkably clear presentation, along with excellent nuts-and-bolts advice, from object expert Martin Fowler. The author is also an authority on software patterns and UML, and this experience helps make this a better book, one that should be immediately accessible to any intermediate or advanced object-oriented developer.
Agile Software Development by Robert C. Martin. Best selling author and world-renowned software development expert Robert C. Martin shows how to solve the most challenging problems facing software developers, project managers, and software project leaders today. A pragmatic tutorial on Agile Development and eXtreme programming, written by one of the founding fathers of Agile Development
And this is a secondary list that rounds things out:
Object Oriented Design Heuristics by Arthur J. Riel. Provides specific experience-based guidelines to help developers make the right design decisions. This book offers the next step for readers that know the basics of object-oriented development and now need to know if they are doing it right and making the right choices.
Object-Oriented Analysis and Design With Applications by Grady Booch. Booch is the man. He is Mr. Object Oriented. Together, Booch, Rumbaugh and Jacobson combined talents and developed the Unified Modeling Language (UML).
Back to Thoughts On Technology Page | Back to Peter's Home Page | Back to Family Home Page
|