Hey, it looks like they hired my in-laws from Alberta to work as security guards at Ben-Gurion airport. I didn't know they were Jewish.

To summarize the story (if you are too lazy to click the link),  a female journalist was traveling to Israel and the security guards found some pics on the laptop that were sorta anti-Israeli. So, taking no chances, they confiscated it and blew it up real good.. It really is a shame. I mean, they shot up a Mac. If it was a Dell or a Sony, I'm sure nobody would have cared.

In all my years of business, I enjoyed traveling to Israel the best. The breakfast buffets at the Daniel were just outstanding. Both of the hotels in Herzliya have private beaches to the Mediterranean so after a dip in the outdoor swimming pool you can walk barefoot in the sand and feel like you're king of the world.

I was able to wangle two business trips on the company dime back in 2003-2004 to some work with the Israelis Creoites on the Prinergy to Lotum Quantum connectivity package. At that the US State department, in its infinite wisdom (stupidity) has declared Israel to be a war zone so it was a complete pain in the butt to get insurance to travel there. Needless to say, it was safer to walk around Herzliya at night than in a lot of US cities. Well okay, until you tried to cross a road on foot. Israeli drivers tend to be a bit, um, aggressive.

I found Israelis to be pretty easy to get along with. No seriously. I have worked with French, Belgians, Germans, Italians, Swedish, English, West Coast American, East Coast Americans, Australians, and Chinese and found the Israelis to be the easy to do business with. They are sorta like Australians with a European flavor, pretty blunt but can't help telling you the truth even if it hurts. And they can get pretty friendly AFTER they convince themselves that you're not out to screw them.

If you need to remote manage a software development project, I would say Israel is one of the best countries to go to. With a lot of other culture/countries, you've always go to deal with the "loss of face" problem if something starts to go wrong.  You know, the schedule is slipping but they don't want to tell you so you gotta sit there on the phone 3000 miles away and guess-estimate just how many weeks you're going to be late. When  you're dealing with the Israelis they don't have any problem in telling you how late you are going to be and they will even tell you how far your management head is up your management ass, if they like you enough. Such honesty is so useful when you are managing a software project.

Reminder to myself. Next time I get to travel to Israel, take a laptop that's been bought off Craigslist. Just in case.

With the kids heading back to school tomorrow (or today, I should say), all the focus is on taking precautions against the H1N1 virus aka the swine flu.
And might I say that this seems to be an opportune time to reflect on one of the blessings of prepress life?
Let me explain: If you are a prepress sys admin, or prepress operator, take a moment to look around your surroundings. How many people actually work in the same room that you work? One? Two? Are you near large pieces of equipment that requires high roofs and plenty of ventilation?
Having worked in the prepress area of more than one printer, I can honestly say that my surroundings were one of the perks of the job. Now you may think that I'm crazy, but let me explain.
A number of years ago, when I was working as independent contractor, selling myself as a project manager or business analyst, I went to an interview in downtown Vancouver for a 3 month gig. They needed somebody to help coordinator a project that had gone off the rails a bit: edit a few Gantt charts, hold some hands, take the blame if things got really screwed up: The usual contractor stuff.
So I get to fourth or fifth floor of the building and walk into a large room and right away two words pop into my head: School cafeteria.
I'm not exaggerating one tiny little bit. Do you remember those long tables in school where you sat with your buddies in Grade nine and ate sandwiches? This was worse. The room was packed with cafeteria tables. Sitting at each and every one of those cafeteria type tables were 6 people, all with laptops and Ethernet cables running to each hub that was placed on every table.
Now imagine one person with swine flu working in that room. I mean no wonder the project was behind schedule, I'm sure that previous winter there was probably a record amount of people who had gotten sick. Come to think of it, what would you do if you had to work there and needed to fart? Jeepers, the more I think about it, the more I think that place was inhumane. It was funny to hear your buddy fart at lunchtime back in high school, notso funny when you're working hard-core on an Excel spreadsheet and everybody is over the age of thirty
By the way, I didn't get the gig. Can't say I was that disappointed.
So anyways, that's why it's good to work in prepress when the flu season is in full season. For myself personally, the years when I managed to swing a sys admin gig, I usually had winters with very mild colds or none at all. But I still remember the two winters I worked downtown in an office sharing a large room with about 6 other people. Killer sore throats and lots of misery. It's not only pigs and chickens that are locked up and kept in pens for an indecent amount of time.

Okay so I was over cruising printplanet and saw this thread. Yes, the question I have seen posted over and over again for the last 10+ years that I have been cruising prepress forums (it feels like an eternity now I have written that). What's the eternal question?

What prepress workflow should I chose? And most usually the poster gives absolutely no information on their shop, the work they do, and the price they want to spend. So the correct answer is "I don't know" when you don't know the parameters that should go into making the decision.

Here you go. Here is a list of factors that should take under consideration when deciding to choose a prepress workflow system. Chose carefully, because if you make a mistake and buy one ill-suited to your needs, you will be stuck in Dante's fifth circle of prepress hell.

By the way, in case you are wondering where the structure for the following list came from, it came from the Volare template guide (short version). This is an extremely useful guide for requirements gathering. If you are REALLY serious about buying a prepress workflow, then you should ante up the $55 and buy the document, as following the guide will mostly likely save you thousands of dollars and hours of your time.

1. Why Do You Want a Prepress Workflow

State Background of the Project Initiative ie where and why this project got started. What are the Goals: How will you define success? Goals must be measurable or else how have you succeeded with the project. The measurement must quantify the advantage gained by the business through doing the project. If the project is worthwhile, there must be some solid business reason for doing it. For example, if the goal of the project is
We want to give immediate and complete response to customers who order our goods over the telephone.
you have to ask what advantage that goal brings to the organization. If immediate response will result in more satisfied customers, then the measurement must quantify that satisfaction. For example, you could measure the increase in repeat business (on the basis that a happy customer comes back for more), the increase in customer approval ratings from surveys, the increase in revenue from returning customers, and so on.
It is crucial to the rest of the development effort that the goal is firmly established, is reasonable, and is measured. It is usually the latter that makes the former possible.
2. The Stakeholders

2a. The Client – this is the guy who will be paying for the software ie not you.
2b. The Customer – This not the same as the owner of the company. Think the manager or supervisor to whom the prepress sys admin reports to.
2c. Other Stakeholders – Anybody, like bindery, sales guys, and pressmen.
2d. The Hands-On Users of the Product – this is you, or the guy that actually has to use the thing.
2e. Maintenance Users and Service Technicians – Self explanatory but you should list them as sometimes it's quite revealing. Like if one prepress workflow has 5 different service techies as a mandatory listing, and the other has zero, then ask the question “why is that?”
3. Mandated Constraints
3a. Solution Constraints
This specifies constraints on the way that the problem must be solved. This is the part of the section to describe limits that are beyond your control to change. For example, you can't buy workflow X because the owner hates that particular vendor (but be diplomatic when you write it, dummy)
3b. Implementation Environment of the Current System – Here you describe your work environment, like your power capabilities and network structure (expect to do upgrades when putting in a workflow system, a $10 hub and a power bar to a standard power outlet won't cut it).

3c. Partner or Collaborative Applications – What other software has to work with the new software (hint CIP3 intergration)

3d. Off-the-Shelf Software (hint: PDF, Quark, and Adobe Creative Suite software)

3f. Schedule Constraints – When do you want the workflow in place by? When you NEED the workflow in place by? (Example, did the company just buy a new press and needs to feed it as quickly as possible?)
3g. Budget Constraints – Yeah, how much is it going to cost, and a better question, what are the financing terms)
4. Naming Conventions and Definitions
4a. Definitions of All Terms, Including Acronyms, Used in the Project
Think about it. Who besides you, know what a three-point trap is? How about FM versus AM screening? You need to carefully define all technical terms so that other people reading the document (like the owner) has the slightest ideas what you are talking about.
5. Relevant Facts and Assumptions
5a. Relevant Facts - Put stuff here that you think is important but you can't think to put anywhere else.
5b. Assumptions - Predictions about the future that you think is going to come true and if they don't come true, could affect the outcome of the project.

I have excerpted about 1/3 of the volare document excerpt and you can see that it's massive. You could easily generate one hundred page business analysis report. Should you? Well, if you are  $2 million a year shop, no. $20 million? Maybe. At least you should print out the excerpt and play the game of fill-in-the-blanks. Note that I haven't even talked about the techincal requirements of the prepress workflow as they are usually the most obvious things that us geeks look for in a system eg, can the imposition package do adjust for creep in  300 saddle-stiched booklet for example. You better be able to nail those requirements with your eyes closed, or you will be for a world of hurt when the system gets dropped in your shop.

Hey, it's late Wednesday night and I'm playing with my Kutano. Hah, hah, that's a joke; I've got a million of them. But seriously, here is Kutano.

In case you can't see the screencap (which means you are blind so you are not even reading this ), Kutano is a little widget thingie that gets installed on the side of your Firefox or Explorer web browser. It's basically a web page annotation tool.

When you visit a web page, you can choose to start a discussion which is visible to all other Kutano users, who can add to the discussion or rank it or start a new discussion. There are some other interesting features like linking the discussion to your twitter account and there's a sidebar which allows to expand views from discussions on the page to discussion on the whole web site.

And that's it, so far. Kutano is one of those applications where you play with it for awhile and then you think, so how is this useful? You know, like Twitter. Well, I definitely know web site designers will find this application extremely handy for marking up and commenting on websites that are under review for changes.  Actually, I know of a few online communities that may find Kutano useful, and I just might spread some of the news there.

The team behind Kutano is here. Yeah, there are a few familiar faces there: Amos Michelson is right there at the top and Kevin Ishiguro, former #2 guy of Prinergy is running the show. Not on the love list is Michael Weber, who is lead developer. In case you're not an aluminus of the Kodak organization, Kevin and Michael were long time Creo developers. I mean, they not only coded parts of Prinergy, but were on the Impact teams (the workflow family before Prinergy) waay back in the mid-nineties.

And yeah, yeah, before the wise guys start to comment, even though Kevin wasn't the best coder on the Prinergy team, he was a tremendous manager. I mean, he organized some excellent meetings in his time at Kodak, and his memos were a work of art.  I think he even made a Gantt chart or two.

(Heh)

Toronto Sun's guide on the inauguration - in the entertainment section.

Good write-up from Winnipeg Sun on the inauguration ball.

The Canadian embassy in Washington has primo real estate to watch whole shebang. They are sending out tweets on the inauguration parade.

What, you were actually interested in prepress stuff today??

(January 21st links fixed, sorry  about that)

And the really great thing about Prinergy is that if you have one, you don't have to worry about document management. Well, you have to worry a little, but it's an order of magnitude less worry than having just a bunch of files dumped on a server.

I spent this morning in a wrap-up meeting with one of my clients, a VP in a mid-sized company, going over the report I had written on their internal print centre. We got to that point in the meeting where it was, yeah, you've got pages and pages of stuff on the print centre and pages of recommendations, but what is the one thing we should do?

So I said well, the print centre keeps all its business forms on a file server in the closet. Yes, it's backed up but that doesn't make it a system. Like if the print centre manager leaves tomorrow who is going to find all that stuff for reprints? Go buy a Prinergy system (They said they would think about it. They always do. It's not a crisis yet.)

And don't think that this company is the only one out there who has this problem, at least in Vancouver. A few years ago I was chatting with another guy who knew the IT scene pretty well and with regard to internal business documents, isolated islands of manual numbered documents rule.

I wonder if most offset printers realize how damn lucky they are that Prinergy has an Oracle database under the hood. Again, I can only speak of the scene in Vancouver, but there are lot of companies around here who are playing loosey-goosey with their documents, meaning if the right people leave at the wrong time, then they are in a world of trouble.

Don't get me wrong, I'm not complaining. That's how us contractors put bread on the table. We wait in the shadows like vultures, and when chaos come we feast on the remains of the battlefield!! Heh, heh, heh...

One well-known factoid in project management world is that 74% of all IT projects finish behind schedule. You know, I would have thought the number would have been higher.

When I worked in the software development group at Creo, I don't think any of my projects ever finished on time (except for one), but pretty well all of them finished under budget. Actually, I don't think I ever had a real budget for most of them. I was given a few guys and told to go do something. Then one day, I was project-managing about 10 guys sprinkled over three different teams (Note: PMing people is different than managing people. What I should say, is that one day I found myself trying to get about 10 people to do something. Which is different than being their functional manager. If you are a functional manager, you get to just tell your people to do something, and they better do it or their butts are in a sling).

Anyways, it's no big trick to get a project completed on time, you either add more resources or de-scope some features. But note that in case one, you are spending more money, and in case two, you are going to disappoint some stakeholder. In my personal experience, it's pretty rare to find a collection of senior management types who are willing to shell out more bucks just to meet some arbitrary calendar date. Oh sure, there are some projects which have very good reasons as to why they need to be completed by a certain date (for example, the Olympics) but it's amazing how often a date is set just because... a project needs a end date. Whatever.

I did have one project that could not be late because the components were to be replacement for some OEM code and the contract to use that code was going to expire. Senior managment had made it know that they would rather crawl over broken glass rather than renegotiate the OEM contract. Surprise, surprise, beta ended two weeks before the expiration of the contract. When a PM has executive blessing to veto all and any scope changes, it's amazing how everybody can adhere to the timetable.

The PMI guys have a nifty name for what is also called feature creep in the software development world: "Gold-plating." This is term for a feature that is added on during the development cycle that wasn't in the original project charter or project plan. Happens all the bleepin' time. It's very bad to allow "gold-plating" in a project, according to PMI.

So naturally, I allowed in pretty well all my projects (they made a PM at Creo before I could read the PMI stuff). To be more specific, if a request came in from the field for a feature or feature enhancement, I would take it to the developers to see how long implementing that feature would add to the schedule. On first meeting, I would usually get the brush-off. Then I would let the matter wait for about 3 days or a week. Then I would follow up. If it wasn't too hard to implement, then we would try to do it. Naturally, the project would be a little late, but if I got happy points from the field, than who cared about deadlines?

Mind you, most of my projects were weeks late or maybe a few months. Proejcts that are massively late are usually either very high-risk projects where everybody is waiting around for some genius to design the crucial anti-gravity components or "drifty" projects that have poor management. Actually, when I say "poor" management I mean managers who are too chicken to kill a project that deserves killin' because they are scared to lose their jobs. So they keep the projects goin' and goin' and hope that senior management doesn't notice that the project that was suppose to take six months is now into year three.

Show me an experienced PM who has never taken an active part in slaying a project, and I'll show you a bad PM.

Right up front, you have to decide which approach is going to provide better QA for your product: Environmental mimicry or egression testing. The choice you make will dictate the people you hire: Subject matter experts (SME) or scripters. And need I bother saying that each choice has its advantages and drawbacks over the others?

Most everybody knows about the importance of regression testing, and why you need a scripter. If you don't, a scripter is somebody who can write scripts that automate the testing. Because if you don't have automated batch tests, then by the time that version 62 of the software rolls around, the test team is just going to focus on testing the new features, and absolutely nobody is going to want to open up the program, click on "save file", and type in "foobar" and hit okay for the 63rd time, and that means regression bugs will creep and not get caught. Some tasks just have to be automated or they won't get done.

But you also need SMEs for environment mimicry, or rather to build a test environment that hopefully shares many similarities with the real world. For example, let's say you have a software application that reads in a PDF file and prints it out to a color plotter. You may need a color SME to calibrate the plotter and plug in the proper ICC profile so that if the plot comes out looking terrible, you will be able to determine if it's the app that is causing the problem or something else.

If you are building a version one of an application, then your tester is probably a SME, a industry expert who works with the developer team in building the test environment, generating test cases, and acting as a sounding board when discussing feature requests. Important note: Discussing features and their implementation is the most fun part of a job for a SME, whereas the first two responsibilities can oftentimes be tedious and annoying. So you need to stay on the SME to make sure they understand that's their job to make sure the plotter has paper loaded, and yes, they need to fill out ALL fields in a test case report.

A good SME is a Godsend, not only acting as eyes and ears for the developers, but also for the product & project managers. A bad SME can make your life a trip into purgatory that lasts well past the completion date of the project. It's most important to hire a SME with really good oral and written communication skills: Somebody who can sling the paperwork and talk to developers is worth their weight in gold. If you are building a version one application, the absolute worst choice you can make is to hire a junior engineer or programmer and have them learn on the job. If the enraged customer base don't tear the poor guy from limb to limb at the first opportunity, then the sales force will pummel the guy senseless at the first trade show. The best SMEs have a reasonable amount of street experience, very good communication skills, and a pretty thick skin. The relationship between your head developer and the SME is key indicator of how well the project is going: If the two are buddy-buddy and give each other excellent grades on their performance reviews, then all is well with the world. If the two can't stand each other guts, then you should be spending a lot of time pacing the bedroom floor at night, losing sleep (and also looking over resumes so you can replace your SME).

Sadly, a development team tends to lose SMEs over time. Usually, as soon as a project is launched, the SME's time is usually taken up dealing with the documentation team, customer support staff, demonstrators, and the sales force. Over the long term, a software development culture where the code-writers are king and everybody else is a second-class citizen, tends to grate on a SME. They either go native (learn to write code themselves) move up into management (like yours truly) or move over to technical sales (where the money is better).

Scripters start to make their appearance near the end of a project, or if the application is a version two or higher. If you have inherited a team with scripters, then you have been blessed, as they are one of the signs of a mature and competent development group (daily builds and proper source controls are other signs). In a perfect world, you would have your SME feed test cases to the scripter who then builds an automated suite that can take the app through sanity checks on a daily basis. However, for this to happen you need a lot of things to fall into place: 1) A scripter who listens well 2) A SME who communicates well and does not feel threatened by the scripter and the automated tests 3) Developers who respect the progress and don't break the automated test suite with gratuitous radical changes to the application.

On most projects, this level of sophistication in building a test environment doesn't occur because of logistical constraints. However, if you are hoping the application that you are building is one that will last for a decade, it's crucial to the maintainability of the code base that you build a strong test infrastructure. Without a good SME, you'll have no eyes and eventually get brain damage from running into walls all the time. Without a good scripter, you'll give up running your sanity tests over the long term, and eventually your application will collapse under the weight of unfixable regression bugs.

So I picked up yet another book on software development and started reading. I wasn't able to finish it because it's giving me such a headache. Every few pages I get the irresistible urge to slap my forehead. At this rate, I'm going to get a concussion by chapter three.

Anyways, this guy goes on about requirements: How not having proper requirements causes projects to be over budget and behind schedule, how feature creep leads to unmanageable project schedule and demoralized developers, yadda, yadda, yadda. No, really?

And his prescription is that somebody write out the requirements and get all the stakeholders to sign off on them. Of course, there is not just one kind of requirement - noooooo! - there are many kind of requirements. As well as user requirements, there are business requirements and design requirement and thingajig requirements and .... I don't know, but lots of lots of funky requirements and gosh, if the project manager gets all the requirements written up and signed off by all the stakeholders, then hallelujah, this will be the ONE project that will finish on-time and on-budget. If only those stupid project managers could write up a good set of requirement documents....thump!

Sorry, that was my head hitting the desk. I think I lost consciousness for a few seconds.

Okay, let's try to refute this viewpoint which seems to be conventional wisdom with the one exception where iron-clad written requirements are the rule: Embedded systems. Basically, it's really hard to change a chip after it's been designed. Duh.

For pretty much all other software development work, it's a good idea to write down a set of preliminary requirements. And then print them out. But print them out on very soft paper that can be used in the smallest room of the house. Because in a very short period of time, that's the only room where that piece of paper is going to be useful.

There are two main reasons why, one obvious & one subtle. I'll start with the obvious: Let's pretend you are the customer. You have signed a contract with a software development house to build a nifty program that does something. You have agreed to pay money. In most cases, you are paying a lot of money. You have put your signature on a piece of paper for something that doesn't exist in the present. You are also painfully aware that when this piece of software is created, if it's does not meet the expectations of your stakeholders, they are going to let you know about it. And how times does a software release meet 100% of the customer's expectations?

Now, after signing a piece of paper for what many in your organization consider an obscene amount of money, a certain period of time elapses and you get another piece of paper to read, with a title stating it's a design/user case/business/whatever requirements document. You read through the document. It looks okay. There's a space for your signature. Maybe you sign it. Maybe you send back an e-mail saying you signed a piece of paper for umpteenth millions of dollars, and that's the only piece of paper need to sign, ever. But let's pretend you sign off on the requirements doc. Does this mean that you, the customer, have given up the right to ever contact, communicate or nag the development team with new features and/or requirements?

No. Never. Ever. There is no customer that has ever existed since the beginning of time that will not continually pester the development for new features right up to the moment of release and after. Get. Used. To. It.

So the lesson for any project manager is not spend too much time on drafting requirement docs. Sure, bang them out quickly, and I mean bang them out, but if, miracles of miracles, the customer sends back an okay and a signed-off document, don't even think your job is finished. The fun has just started.

This brings up my second point about falling into the documenting-requirements trap: getting all the requirements is super-hard. In most cases, it's impossible. Not even the customer, and the customer of the customer, can give you 100% of the requirements.

Look, it's like going to Julia Roberts fan club and saying: "We want to make a love story with Julia and Brad Pitt. They fall in love, they fight & break-up, and then they make up and fall in love again. At the end of the movie, everybody in the audience because the movie was so wonderful. Here is the script of the movie. Can you assure us that after seeing this movie, you'll reach for your hankie?"

Let me recount an example from the real world (I have changed some of the details to protect the innocent): One of Creo's customer had some printing technology that was running with a software suite developed in the early 1990's. Creo has some pre-press software developed about a decade later that is vastly superior. However, there were some unique features that were needed to be developed and added to Creo's software suite.

Project management for the customer was being coordinated out of head office in mid-US whereas the printing technology was based at plant site near the West Coast. I flew down to the plant to show off Creo's software suite and capture requirements. Did the presentation, flew back to Vancouver. A couple of weeks later, we get the diplomatic message from head office that perhaps all the requirements have not been captured. So I fly down again. I also arrange to have Creo's software suite loaded on a server and shipped to the plant site as a loaner. This time, during the presentation, they have their super-user, their system administrator on hand. I am lucky that the customer is smart enough to get their users out to the presentation to critique the suite. The super-user goes deep on me. That means she drills down many levels to some really obscure (to me) but important (for them) business requirement that is not in our software suite. I promised to follow up on those features with some of Creo's SMEs (subject matter experts) when I get back to the office.

Meanwhile, the server with Creo's software arrives on-site with a local field rep to do install and preliminary training. I also arrange for a trainer to follow up with an on-site visit to the customer a week later. I pre-brief the trainer to watch & report for any new requirements. Six weeks later, I send another trainer. About five months have passed since my first visit to the customer suite. Finally, the super-user is able to articulate the requirements that the plant needs to the Creo representative who is also a SME in that particular sub-topic. So we get the requirements captured and we pass them on to the development team and we get the message back that none of the requirements are impossible to fulfill, it will take about three months to roll into the next upgrade. End of story.

Now, note that in this case study:
1. The customer was sophisticated, understanding that we needed to have the super-user spend lots of time playing with our software so she could discover what was missing.
2. We had lots of time. Getting the proper requirements took five months. Coding the requirements took two weeks (the administrative load of rolling new upgrades into the software suite accounted for the other 2.5 months).
3. This was a modification of a pre-existing software suite. We were not presenting the customer with a "blank piece of paper."
4. The business was worth enough to send a loaner server with the software to the plant AND have a total of five separate visits to the plant (two trips by the project manager, one by a local representative, and two by trainers).

In conclusion, the point of this essay is that getting requirements in the real world is not so much a point of documentation, but an iterative process with the customer that goes on through the life-cycle of the development process (and beyond).
I'm gonna try to finish the book I'm reading, if only to present myself to future employers as fount of (conventional) wisdom. But really, if the woods are full of project managers who think they are home-free once they document the requirements of a project at the beginning of the development cycle, then it's no wonder that a lot of them get shredded after a few years in the biz.

This post is a synthesis and continuation of some ideas that have been covered in other posts on this blog: Why volatile investments sucks, the 85/95 rule of project management, and Gantt charts versus PR database. If you have read all of those posts, then what follows might make sense to you. If not, then I guess we'll see just how good a writer I am.

To dumb it down somewhat, I'll use one of my favourite literary devices: The parable. Here is the story of Ploddin' Paul the project manager who is faced with a very difficult management decision. He has a team of 5 developers, of which three are senior developers and are capable of handling mini-projects on their own. Their names are Genius Gary, Engineer Eric, and Liason Larry.

The project is a somewhat risky one, but not overly so. The goal is to build an archiving interface to several different models of tape drive so that customers logging into a database have the option of leaving their data on-line, saving it to a tape drive, or restoring the data from tape. Of course, there are number of other features and design requirements. The project is to be delivered in 6 months.

The team has three choices: 1) Write the code from scratch 2) Re-work some existing code that was produced in-house or 3) Work with a third-party API that promises to deliver much of the functionality (published by a vendor called Babooza).

"The APIs of Babooza suck big-time, let's do it the right. Write the code from the ground up in C#," says Genius Gary, who is the best programmer of the lot but has the attitude to go with it.

"The least risky way is to re-work our existing code base," Engineer Eric says. "We already know how difficult it is to work with the drivers for the tape devices. Yeah, there's hair in the old code base but that's the devil we know."

"In six weeks, Babooza says they will deliver an API that takes care of most of this." says Liason Larry. "Why do any of this if those guys will do it for us?"

"Trust Babooza? You're nuts. And our old code base sucks. Everybody knows that. Go new."
"I agreed with you about Babooza. But you want to leap off into deep water with no lifejacket. Go old."
"But what if Babooza delivers something functional? We'll could have our developers add more features and a really good GUI instead of goofing around trying get the tape drives to archive."

At this point in the conversation, just about when the developers are about to run to their desktop and settle the matter by playing a deathmatch in "Unreal Tournament," Ploddin' Paul speaks up:

"Larry, what do you think the odds are of Babooza delivering the API on time and it being usuable?"

"Ah, I dunno, maybe 50%"

Both Eric and Gary make noises and Paul marks that down to 25% in his head.

"Gary, if and another developer work on building what we need from scratch, do you think we can ship on time?" asks Paul.

"Naw, too much work, I would need at least another guy."

"What if I gave you a guy three months in? Maybe two."

"Okay, 80% chance of being done on-time."

Now it's Eric and Larry's turn to roll their eyes. So Paul marks down the odds to 40% in his head.

"Eric?"

"C'mon Paul, give me the whole team and ninety percent sure it's going to be delivered."

"Hairier than the back of a gorilla," Gary says in a loud whisper to Larry. "Think spa-ghetti."

"Eric, if you're just re-working the code, how come you need headcount of five?"

"Come on, the more the merrier. There is going to be a lot of debugging."

"You get one guy for now, with maybe more in three months. So are you still 90% percent sure?"

"Ah, no promises," says Eric

Paul mentally marks the odds down to 50-50. He has had a look at the code. It's terrible.

Paul makes his decision. "Everybody go off and do their own thing. We'll come back in three months and review." Everybody nods their head and walks off. It was always like that, with Paul never making a decision on the final path to take until the very last possible moment. It drove some of the developers completely nuts sometimes, with the odd grumble that the group always seem to be on the verge of complete anarchy. But Paul DID let everybody try their own way most of the time, so people were most happy. It just seemed so inefficient...

***************************************************************************

So, on first read, it looks like Paul is violating one of the golden rules of project management which is always work hard to change your 85s to 95s (that is to say, always try to up your odd of success, no matter how incremental it may be). Paul is forsaking some paths which promise a 90% percent chance of success and letting developers pursue some high-risk approaches. Also, I have to say that this approach would look like crap if you threw it up on a Gantt chart: Instead of clean little bar showing five developers working together as a team towards a common objective, you've got three bars working in parallel towards the same goal. At some point in the chart, you've got to end two of those tasks, with all the waste of resources that implies (In Paul's case, the decision point is halfway into the project or three months).

To summarize: The developers do not think Paul is a decisive project manager, and definitely, if Paul's boss lived and died by the Gantt chart, he would wonder why Paul was wasting resources with all the redundacy.

But once again, the math works for Paul, because in software development, parallel paths with a reasonable chance of success are a better than one path with a high chance of success. Note that parallels path means you add the percentages together, not multiply like in a sequence:

One path: 90% of success.
Three paths: 25% + 40% + 50%= 115% of success!!

Of course the 115% doesn't mean that the project is absolutely sure to be completed successfully and on time. These percentages are gambler's percentages, meaning that sum is the addition of a series of bets for a given payoff. A metaphorical story might make things clearer.

Let's pretend we are in casino rather than in a software development environment. You have $500 in your pocket and the prize is...Oh, I dunno... an brand new Ipod (The best version, the one with 40 gigs. The one my wife won't let me buy 'cause I don't have a job, even though it would make me really, really happy if I could).

You can place all your money on one bet and have a ninety percent chance of winning. Or you can make a more complicated series of bets like Paul did: You put down $100 and have a 25% chance of winning. You also simultaneously put $200 down and have 50% chance of winning and put down another $200 to have a 40% chance of winning.

And here is where the fun comes in: With the first bet, there is one spin of the wheel and you know whether you are a winner or a loser. If the estimate of the development is correct, you are a winner nine times out of ten.

But with the three bet scenario, you have three spins of the wheel, and if one of the spins comes up a winner, you get half your money back from the other two bets. For example, if one of the $200 bets comes up a winner, you would get back $150 (50% of the $100 and $200). That is to say, if Gary's approach looks to be a winner after three months into the project, then you can abandon Larry and Eric's approach.

But what happens if none of the bets comes up a winner? Aha, well if that happens, the casino will allow you to double up your bet and spin again, taking half of the total sum of your bets ($250) and allowing you to spin again (With the chances of success not know until after the first 3 spins are completed). That is to say, if after three months, the API from Babooza totally sucks, and Gary's team can't even do a daily build without the compiler going into hysterics, then Paul can make the decision to throw everybody on Eric's project to rework the old code base.

In short the complex, almost chaotic allocation of resources in a software development environment allows for a better chance of a project being completed, and for a more efficient use of developer resources. I stumbled across this discovery mostly by accident, when I was grumbling about the inadequacy of gantt charts to accurately describe what really goes in a true development environment. For sure, I didn't expect to find a mathematical proof for the behavior that I saw in the PWS (software) division of Creo.

Anyways, for me this is a really cool discovery, because it validates the everybody-run-around-and-do-your-own-thing-and-let's-make-a-decision-later approach. Well, I mean the math validates the theory. Hmmm, I don't know if I would to try to "sell" this approach in a job interview or something like that.

Cheers, Dj

P.S. If, in software development literature, anybody has come across ideas similiar to the ones presented above, please drop me an e-mail so I can link to it. It's quite possible (maybe even probable) that this "Anarchy is Good" theory has already been discovered and I am just ignorant of it. Thx.

The content for this website is provided by www.bluebutterfly