If a piece of software is described in any way, shape or form as being "enterprise", it's a safe bet that you don't actually want to use it. As a general rule, "enterprise" software packages mix the Inner-Platform Effect with trying to be all things to all customers, with thousands upon thousands of lines of legacy code that can't be touched because at least one customer depends on those quirks. There doesn't tend to be much competition in the "enterprise" space, so none of the vendors actually put any thought into making their products good. That's what salesbeasts and lawyers are for.

Kristoph M supports a deployment of Initech's data warehouse system. Since this system is a mix of stored procedures and SSIS packages, Kristoph can actually read a good portion of the code which makes the product work. They just choose not to. And that's usually a good choice.

Alice's team was thirty developers, taking up most of the floor of a nondescript office building in yet another office park. Their team was a contractor-to-a-contractor for a branch of the US military, which meant a variety of things. First, bringing a thumb drive into the office was a firing offense. Second, they were used to a certain level of bureaucracy. You couldn't change a line of code unless you had four different documents confirming the change was necessary and was authorized, and actually deploying a change was a milestone event with code freezes and expected extra hours.

Despite all this, the thirty person team had built a great working relationship. They had made their process as efficient as they could, and their PM, Doug, understood the work well enough to keep things streamlined. In fact, Doug did such a good job that Doug got promoted. Enter Millie, his replacement.

It's still a holiday weekend in the US; after playing with fireworks yesterday, most of us have to spend today trying to find the fingers we lost. There are no fireworks in this classic story, but there may be some karma… Original --Remy

When Kevin landed a job at Townbank in the late 1980s, he came face-to-face with the same thing that thousands of newly minted developers had encountered before and since – there is more to being a corporate programmer than just writing code – there’s the process.

Second only, perhaps, to the strict rules commanded by the world’s religions, the process keeps the code consistent. Glory to the process – praised be the process - the process is good, the process should always be followed, and above all, the process is good for you!