enginpost.com

Object Oriented Web Development and Why Managers Don't Get It

I graduated from college in 1997.  It took me five years to get through school mostly because I was paying for it as I went and honestly not quite sure what I would major in until it was almost too late.  Ironically, I was studying business and at the same time taking computer programming classes for fun and quickly needed to pick a major or just sign up to endlessly be a student (which was not something I wanted to do.)  So after talking with the teachers I knew the best, I was ready to switch over from the business department and get a computer science degree while completing a marketing major.  Happily, the school suddenly added on a Management Information Systems degree, so I ran to my councelor and after running the numbers we determined I was just a couple credits shy of having accidentally selected the MIS major (before it even existed.)

The credits I was missing had everything to do with completing a senior project in MIS and a couple of theory classes (stuff I had already learned but now there was 200 or 300 level classes suddenly on the topic.)  This kept me in school for the fifth and final year, but it was the quickest route to "out" as opposed to starting up a fresh Comp Sci degree.  I was set.

In my final year theory classes I had to learn a development language called "smalltalk" where we were introduced to the immutable rules of object oriented programming.  Here I am many years later and I can say that those final courses made the most practical difference in my career.

Upon completion of my undergraduate degree, I got a hold of my councelor and asked about pursuing a graduate degree.  I was encouraged to pursue a graduate level MIS degree and so I went to chat about this with the professor leading the degree program (he happened to be the same teach I consulted with earlier.)  At that time the professor asked me how I did in my HR Business courses, my analytical courses, and he took a look at the grades he had given me over the previous years.

"Steve, you aren't going to learn a thing. The graduate MIS program is designed to move business professionals over into thinking like technologists.  We won't teach you any business courses that you didn't already do well in during your undergrad days, and you could teach the 400 level MIS classes at this point. Just go get a job and if you really want the credential then come back and talk to me." I never went back.

In retrospect I think that non-technologists who manage technical projects as business people should take the time to get such a degree.  Over the years I have worked with great project managers who have mentored me from not knowing what I don't know, to realizing how to identify gaps and systematically go after filling those gaps. It ends up that MIS PMs who don't get MIS but who aren't at least familiar with the fundamental rules of project management end up have typically one road to success: they have to manage the work breakdown structure dilligently.  If they aren't paying attention to schedules at the WBS level AND MIS escapes their understanding, then trouble ensues and the most traditional benefits of implementing organized technical approaches fails to yeild any benefits.

Object Oriented Development (specifically web development) in the end becomes a buzzword that the PM might be able to offer a definition for, but they likely couldn't identify OOP when it is happening.  In fact, due to a lack of understanding, OOP and code architecture still end up being the first values set asside when projects press the schedule. When that happens objective values like flexibility, scaleability and reuse immediately get picked off, too. Killing OOP ends up killing a number of other buzzwords that all have value, but if they are simply buzzwords, then they get reduced to selling points and the PM get's reduced to, at best, a client expectation manager or, at worst, a sales-person.  In my world, while everyone plays a roll in representing the company, nothing is worse than a PM who thinks their priority is client-management or sales! When those rolls get confused, projects fail.

So, why don't managers get OOP? In my humble opinion, most managers are implementing the benefits of OOP in their career.  They want to keep themselves, their careers, their project and their teams flexible, scaleable and maximize reuse. But where one thing can be convex, another adjacent think must be concave. If the manager wants their career to be flexible and scaleable, something else has to give way in order to make room for it. And because traceability and measurement often goes out the window (where the only real measurement is "did we get it done?") bailing on values and buzzwords is much easier than counting the cost inevitably.  A classic example is valuing delivering on time over delivering quality over the life of the deliverable. Another example is getting a quality work completed on time, but at the expense of the personal time and stress level of staff over the period of performance.  I can't tell you how many times I have heard (fellow) managers (I am not a manager right now, formally, but have been) act like the stress they cary as a (disorganized) manager defines their value while the similar stress carried by production people while actually doing the work is somehow not more valuable.

In the not-to-distant past a company I have worked for employed a PM that made all of these blunders. That individual was not organized, didn't understand the principles of good PM, had a bit of MIS understanding but not an amount equal to the decisions needing to be made. Due to his disorganized nature, he personified stress and as a result stressed out everyone beneath him responsible for production. At one point, the company above him began to recognize the dilemma and it was decided that the most significant loss to the company if he were to leave would be the stress as opposed to the loss of non-existant PM activities.  He soon left and the company went on without him.

Six months later the company still neglected to hire someone to replace him.  The stress was gone on one front, but was quickly replaced by the stress resulting from a void in leadership.  While the man did a poor job, the buck often did stop with him, and now the buck stopped no where.  His technical semi-expertise was gone and now a void continued to exist while those even less traditionally qualified were making decisions. But the value of the saving with regard to not re-employing someone like him but who could do a better job, apparently outweighed the value of getting someone in who could fill these voids.

The company goes on, moving forward, but the value of technology or systematic approaches seems to ellude that group creating a glass ceiling for growth and opportunity.  The bottom line is, the benefit is, in fact, in the details, and you cannot outsource understanding.  As long as managers want to avoid the stress of dealing with details in a professional manner and feel they can outsource their understanding by attending bussword seminars or reading bussword books, they will never "get it."  And the problem is that "getting it" is what creates opportunity. 

You can't just want it, or see it, you have to get it.