Wayne Allen's Weblog

Multidimensional Methodologies

In preparation for the upcoming SPIN panel the (common) question was asked. "Is there a continuum with Waterfall on one end and Agile on the other?" My response is that the differences are multidimensional and relate more to where you are and where you want to go. So I came up with a way to look at various different software development methodologies and came up with this.

I'm still working on the significance (if any). In any case a few observations:

• Moving from an ad hoc process to any other process will be difficult since so many dimensions have to change.
• Moving between the agile processes (FDD, XP, Scrum, Crystal) won't be so difficult since few dimensions have to change.
• Scrum being mostly a project management method has an unusual shape and combining it with any of the others causes its diagram to flesh out.

I'm sure there is more work/analysis to be done in this area. Anyone seen this before? Or have observations of their own?

20 Year Applications?

A client I am working with is porting several green screen applications to J2EE and one thing that keeps popping up is that we need to develop an architecture that will support these applications for the next 20 years just like the last one did.

Dan Appleman posted about how he doubts that Microsoft will promise to make Windows Forms viable for the next 15 years. I must say that I doubt Sun and IBM will promise to make WebSphere and the J2EE 1.2 spec viable for the next 15 years either (not without significant upgrades from time to time).

I am not naive enough to believe that 20 years ago a few developers wrote our existing COBOL systems and they've been running perfectly ever since. I expect several hardware and software versions caused upgrade headaches as well as the ongoing maintenance that keeps users happy. But J2EE, WebSphere and all the components that hook things together (Hibernate, Swing, web services, etc) are fairly immature compared to COBOL in 1984.

So how does one help create a 20 year system given todays platforms?

Incrementalists versus Completionists

Joel turned me on to a Rands In Response posting titled "Incrementalists versus Completionists" where Rands relates a discussion with a co-worker where the co-worker found a problem, Rands suggested a temporary and incomplete solution that could be achieved in the time allowed. Rands was then stunned to find out his co-worker saw that as worse than doing nothing.

He breaks this down into those "dreamers" want to do the whole thing right or nothing (completionists) and "realists" (incrementalists) who are the good, smart guys who get things done.

Now I place myself in the incrementalist category, but not for the reasons that Rands suggests. Rather having been down the road of the archetypal completionist architect I have discovered the joy of getting stuff done in an incremental fashion toward my goal of the right thing. Because the thing I discovered was that my idea of what was the right thing kept changing as I learned new things. Both because of factors external and internal to the project. Interestingly Joel actually made me think about this for the first time in his article "Things you should never do, part I"

The reason any of this is interesting to me at this moment is the client I am working with wants to "do architecture" for several months as part of a application port from COBOL & Natural to J2EE. This stikes me as very completionist as conversations tend to be along the line "if we can just nail down the right architecture..." Another company I'm talking with wants to spend 4,500 hours developing the right architecture so they can port all their existing applications over to it.

My question in these situations is "where is the value"? Is there any value to changing the architecture when everything is already running acceptably? In the case of moving off the mainframe you might be able to make a case. But unless the end user is going to see some improvement in something they care about, I believe changing the architecture to be better is nonsense.

Advice for Software Development Managers - Jerry Weinberg

Check out the interview Software Development Magazine did with Jerry Weinberg.

Quotes that struck me:

"If you blame your employees, you're a bad manager. You hired them, accepted them, supervised them, and directed their training. You’re responsible. If you don't like what's happening, look to your own behavior. But, if there's credit to be given, it's theirs."

"I might add something about how to make yourself so valuable that your work will never be outsourced -- something about the arrogance and overconfidence that has led to the loss of lots of software development jobs, not just to outsourcing, but to development work that's just not being done because the odds of success are so poor."

"Even in those rare cases that people pass those first two hurdles, they lose emotional control during the project when something goes wrong -- and something ALWAYS goes wrong. In 50 years, I've never seen a project where something didn't go wrong. When it does, the project’s success is determined by the leaders' ability to manage themselves emotionally."

Maintenance Team? Balderdash!

In many organization I've encountered there is this artificial distinction between the new development group and the maintenance programming group. Why on God's green earth would you want to do such a thing?

Every time the topic comes up I point out that there is only "maintenance" since once you have the first line of code checked in you are now maintaining the system. Probably the only difference between "new development" and "maintenance development" is whether the system is being used in production or not!

A better approach in my opinion is to view all your systems as the software ecosystem for your organization. You now have the common problem of limited resources to change/add features to the ecosystem. The features may or may not be added to systems that already exist. Whether the system already exists is irrelevant to the decision to spend money on that feature.

Organizations that have adopted agile practices eventually notice that there is little or no difference between new functionality, enhancements and bug fixes. If there is a difference it is more a difference of granularity in that some bug fixes are very small while everything else tends to be larger.

The advantage of the ecosystem approach is that your development resources are more of a pool that you can draw from, the stigma of being on the maintenance team dosen't exist, and knowledge can be spread among the team.

Think about it, try it. You might like it.