The Future's So Bright...

Back in the 80's there was a hit song entitled "The Future's So Bright I Gotta Wear Shades".

The prediction may have been a bit premature then, but I think it's pretty accurate now... and I think we have high gasoline prices to thank for our bright future.

Gas was too cheap. There just wasn't any money in alternate energy technologies, so companies and researchers didn't aggressively pursue them. Just as with NASA's early efforts: "No bucks, no Buck Rogers".

Money makes the world go round, and now Petroleum isn't the cheapest kid on the block.

Here are just a couple of promising options that are finally cost effective:

• Electrolyzed Hydrogen from Solar Cells.
• Carbon-neutral Bio-diesel from Algae
• Solar Cell Roofing
• Cheap Wind Power

Folks who think that the key to our Energy Future is to keep burning Fossil Fuels just don't get it... the answer isn't to suck more oil out of the ground.

Most Software Development Obstacles are ______

Fill in the blank in the following statement:

Most Software Development Obstacles are ______
(A) Technical
(B) Cultural

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) were all 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 (they value things differently than you).

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 ;-)

Managing the Garbage Collection Process

For those of you who follow my Java oriented blogs, don't continue reading this if you're looking for information on Java's Garbage Collection... I'm going to blog about real-world trash today:

In my neighborhood in Austin, we have weekly curb-side garbage collection. The city provides me with a large plastic bin that has attached wheels, and on Friday mornings they'll empty this bin and haul away the garbage if I've remembered to drag the darn thing out to the curb.

Within the Reynolds' household, "taking out the trash" is a weekly Process whose Activities have been assigned to me by the boss my lovely wife Teri. "Taking out the trash" isn't a complicated process (in theory)... there are only a few steps:

1. Gather trash from the various trash cans scattered around the house.
   
2. Wheel the trash bin from the side-yard to the curb in the morning (before the garbage truck arrives).


3. Wheel the trash bin from the curb to the side-yard when I get home from the office.
   

In practice, "taking out the trash" almost never works smoothly. Step 1 (gathering the trash) almost never occurs without an Escalation Task Notification from my supervisor that the Task is overdue. For some reason she always remembers "Tomorrow is Trash Day" long before I do (selective memory, no doubt).

There's also the problem that Step 1 almost never meets its SLA (Spouse Service Level Agreement)... I inevitably forget to empty some of the small trash cans in some out-of-the-way rooms (like the kitchen, bathroom, living room, etc.). Once again, Escalation to my supervisor is almost always required (She usually ends up doing it herself).

Obviously, the Management Team of the Reynolds' household ought to invest in a good BPM system and turn this into a Managed Process ;-)

My little Process is only a small Sub-Process of the City of Austin's Garbage Collection Process. They've divided the City into geographical districts that are serviced on different days of the week. Everything goes off like clockwork except for a few times a year when Holidays cause the schedule to slide by a day or so, and during special periods where the volume of trash increases dramatically (Christmas, Bulky Trash Day, etc.).

The City is pretty good about sending out schedules far in advance of any changes in service, but you still see a lot of trash bins out at the curb on "slip" days. Some folks (me) just can't seem to keep the schedule straight.

As a Managed Process Guy this is obviously a deplorable situation. We ought to Analyze the Current Process, Model an Improved Process, Implement the Improved Process, Monitor Its Performance and then repeat these steps until we Perfect the Process.

If each trash can in my house were actually a Robot (something like a Roomba), then the trash cans could gather themselves... rendezvousing on the side porch to empty their contents into the City's trash bin.

The City's bin would also be a Robot, in constant touch with the City's fleet of Robot Garbage Trucks. The Robot Trucks could signal the Robot Bin when in the neighborhood... the Robot Bin could signal its little flock of Robot Trash Cans, and I could watch TV for a few more minutes.

The only problem with this Grandiose Process Improvement Scheme of mine is that the Return On Investment is most likely non-existent. It's a great idea (from my perspective) but the Cost will never justify the Benefit).

Cost... That's the real point isn't it?

What does the Current Process cost? Are there opportunities for reducing that cost?

To answer either of these questions you are going to have to define "cost"... Cash outlay, time spent, bad feelings, etc. Once you've defined "cost" then you are going to have to monitor the factors that contribute to "cost"... Only then can you begin to have an objective discussion on how to make the Process better.

So... The first step towards resolving the Garbage Collection Process pitfalls in the Reynolds' household and the City of Austin is to Manage the Process "Just Enough" to Monitor it. Hopefully the cost associated with my forgetting to perform my assigned tasks will justify the purchase of those Robot Garbage Gatherers, but somehow I doubt it ;-)

Tips for the Business Process Developer - Task Visibility

A task doesn't get done until someone knows that it needs doing...

That's a fairly obvious statement, and one that we often take for granted when implementing Managed Business Processes. As a process-engine steps through a process it assigns tasks to participants... and presumably the participants are notified as the tasks are assigned.

The most common way of notifying a participant of a task to perform is to add an entry to their task list and then send the participant an email telling them to check their task list. If the participant constantly checks their task list, the email is unnecessary, but you'll often have a mix of participants who perform tasks on a regular basis and those whose participation is much less frequent (like a manager handling an escalation task).

Often you will encounter the request to bypass visiting the task list altogether... just let the user perform their tasks via email. There are a few technical caveats to satisfying this request (such as authenticating the user), but it's not an unreasonable request. For a simple task such as an approval there may be very little feedback that you require from a participant, so why not let them fulfill the task via their BlackBerry?

On pondering this common request to perform tasks via email, I almost came to the conclusion that a BPM solution doesn't need a task list at all:
- Why not just use the client's email inbox for this purpose?
- Why do we need a separate task list at all?

The answer to that last question might well be "No". Maybe we don't need a separate task list to hold the tasks that we've been assigned. Maybe all we need is a filtered view of our standard email inbox.

The only real difference (that I can think of) between an email inbox and a task list is the dynamic nature of the task list. My task list contains tasks that are specifically assigned to me as well as unclaimed tasks that are assigned to the groups that I belong to. As I complete my tasks, they dissappear from my task list. If someone else claims a task that is assigned to one of my groups, then that task also disappears from my task list. If my email client supports "recalling email" then I can accomplish pretty much the same behavior.

The statement "pretty much the same behavior" is what leads me to think that we still need a separate task list for our BPM solutions. There's obviously great benefit in exposing task assignments via email (or text messaging, or paging), but the task list itself can encompass much more than simple notification...

So what do you think? Is a BPM specific task list necessary, or will your email inbox suffice?