If you are a Developer who builds sites where folks go to "do things", then I hope can inspire you to think a bit about those "things" as part of a larger Process.
It's not a huge leap to build into your site the hooks that a Process Guy like me needs to incorporate your site into a larger Managed Process. I'll be grateful if you make the effort, and I'll bet the users of your site will be too.
Please check out the details on my other blog.
From where I was standing at the time I'd have to say Object Oriented Methodology. Our practical experience with software led us to value encapsulation, inheritance and polymorphism - but we didn't have to tools to enforce those concepts in our code. End result: We knew how to write good code but it was awfully hard. We had to hand-craft coding conventions that Object Oriented Languages gave us for free.
Object Oriented Languages led to a Renaissance in programming... The tools codified the methodology - leading to unquestioned validation of the methodology - leading to wide adoption of the methodology. Said another way: Most programmers began to think in terms of Objects.
Methodology by itself probably would not have led most programmers to think in terms of Objects. Languages by themselves probably would not have led most programmers to think in terms of Objects - If you don't believe me go back and look at most of the C++ code that was written in the early 90s (most programmers continued thinkin in C for several years).
Object Oriented Design and Object Oriented Languages have been a huge factor in my programming career - but they aren't enough. Objects are just a subset of what I need to solve the problems that I have been asked to solve. I deal with Processes and I deal with Services.
Processes and Services are hand in glove - Processes Orchestrate and Choreograph Services - so any good Process Tool has got to also be a good Service Tool.
There are some really good Process and Service Tools out there - but they're mostly proprietary (expensive). Those of use who are fortunate enough to use them have really been able to immerse ourselves in the methodologies - We think in Processes and Services.
Most of the widely available Process and Service Tools feel a lot like C++ to me... They're Object Oriented environments that have "just enough" Process and Service tacked on to be useful - Many folks who use these tools still mostly think in Objects.
It's hard for me to convey exactly what I am talking about - unless you yourself think in Processes and Services you probably won't grok the nuances that make them powerful - but here's a stab at something that you might be familiar with.
The Spring Framework has a very good component (Spring Web Flow) for controlling the flow between web pages that are presented to a user. If you're a Process guy like me, this is a wonderful little subset of what's available via BPMN. You are essentially modelling a Process with a single participant as they navigate through a series of screens.
Unfortunately, the IDEs that support Spring Web Flow pretty much shuffle it off to the side. They encourage good old OOD with this funky little XML thingy that you use to govern page flow.
A Process Oriented IDE would turn this paradigm on its head - When you started a new project you would begin with the Web Flow. Your Pages would begin life as stubs with just enough functionality to set the data the Flow Controller needs to get to the next Page. Instead of a "folder tree view" of class hierarchies, you'd find the elements of your project by drilling down through the Flow diagram to the Pages and the underlying Services (objects) that support those Pages.
What I've described is pretty much what you'll find in the top-tier BPM products... Use these tools and you'll quickly start thinking in Processes and Services.
Once again this reminds me of the early days of OO - Smalltalk was impractical for most of us, so we had to make due with C++. The mainstream programming tools were still procedural (rather than object) in flavor... but in just a few years the critical mass of programmers started thinking in Objects. The rest is history.
My guess is that Process Methodology and Tools are at about the same point where OO Methodology and Tools were in the early 90s... What do you think?
My friend Bob was troubled when I blogged "Object Only Programming is Silly". Bob knows from experience that life after OO is dramatically better than life was before OO... so my criticisms just don't sit well with him. Obviously I must have gone off the deep end :-)
If you're interested in Bob's thoughts and my reply, check out my ramblings: Another look at Object Oriented versus Process Driven Design.
Fill in the blank in the following statement:
Most Software Development Obstacles are ______
If you answered (A), then I am intensely jealous :-)
When I became a programmer, my answer definitely would have been (A) and I probably wouldn't have had a clue why (B) was even on the list. I doubt that I had any idea what "Cultural Obstacle" even meant in the context of Software Development.
I was drawn to programming because of the technical challenges (I love solving puzzles and building things). My University classes (except for electives) all of the classes that I took at the University were concerned with Science and Engineering. Now I realize that I should have taken some basic classes on Psychology.
Let me give you one example:
The implementation methodology that I practice and the one that I encourage others to practice can be expressed pretty simply:
Build "something that works" and start using it. Identify the next most iimportant thing to extend or enhance and then build and use that thing. Continue these cycles until everything is "good enough".
I now call this "iterative development"... but I use to call it "the shaft of light theory". Others might call it Agile.
I arrived at this approach pretty early in my career... as I think many of us do. I found myself working on overly ambitious projects that just seemed to drag on and on with no end in sight. Nobody knew what worked and what didn't. Everything on the project plan was 80 percent complete.
As deadlines approached we'd start dumping feature right and left until we got down to the stuff we could actually finish by the due date.
On top of that we'd often "finish" only to find that the output of our labors wasn't what the end user really wanted. Perhaps we had misunderstood or perhaps they had changed their minds. Regardless, nobody was happy despite our hard work.
I am a huge fan of "play backs"... Demonstrate the application to the users as you develop it to insure that what you are building is what they need. Often the requirements will change as the users become fully aware of what (you think) they asked for... and that's okay with me.
Admittedly, this approach won't work for everything... but for the jobs that I do (where there's a lot of human interactions) it works most of the time.
Most of the Quality Assurance people that I know hate my approach. How can they assure the Quality of the product if the requirements are in flux?
Look at QAs objections from a process perspective: one measure of a good process is the amount of necessary rework - less rework is good, more rework is bad.
From a QA perspective iterative development is bad because it requires them to do a lot of rework - testing "the same" functionality over and over. Prior to a production deployment everything must be tested, and in many cases even regression testing is foiled by new requirements.
From my perspective this is a small price to pay... It's more important to get "something" to the user as early as possible, and we're much more likely to build what they really need.
I have to admit that QA has a point though... Without a comprehensive plan from day one... How can you reliably estimate when you'll be done?
I've focused on QA and Development - but you know the same applies to Security, DB and Network Admins, etc. Each have their own jobs to do and their own ideas on how to do their jobs well.
There are no right answers here... It's a clash of cultures rather than a question of technical merit.
"Measure twice and cut once" versus "Shave off a little and see if it fits".
Both approaches "work"... But they don't work together.
What's crucial is for each organization to develop a culture that works for them. If you hire an Agile Development Manager then you'd better hire an Agile QA manager. Some might argue that it's good to have divergent viewpoints within an organization, but my experience has taught me that everyone is much happier (and everything works smoother) if the department heads agree on the fundamentals. I don't agree with executives who believe that underlings who fight with each other produce better results.
So what do you do when you find yourself working with others who disagree with your approach? What do you do when you disagree with their approach? My guess is that you've already dealt with these questions many times... sometimes with positive outcomes and sometimes with negative outcomes.
Hopefully your positive outcomes are on an upward trend... If not it may be a good time to reflect on "life, the universe and everything" and adopt a more effective approach for dealing with others.
They may be morons. They may be idiots. They may even be slackers and lazy. But I doubt it.
They probably just belong to a different culture than yours.
If you want to be an effective programmer, you are going to have to find a way of dealing with them - or your efforts will be wasted...
Welcome to the wonderfuil world of programming ;-)