Internetworkers: http://www.ibiblio.org/internetworkers/

[mdthomas at mindspring.com (Michael D. Thomas)]

> There's a lot there to address and the changing nature of software
> development affects what can be achieved and not.
> As an employee, I've actively tried to create informal conversations with
> salespeople, partly to find out what features/requests customers were
> wanting, but with the more subversive goal to inform them what can and can
> not be done.

Thus avoiding the classic "Can you believe what they just sold?" scenario.

I've worked on both sides, so I have empathy for the salespeople that
accidentally sell non-products. So much of the salesperson's job is keeping
the customer from realizing they can live without the vendor. There's a
certain rhythm and music to the customer communication, and in any
conversation the salesperson must sing, "Yes, by next week!"

On the other hand, there are the developers that expect that all projects must
proceed with a lot of RUP-style design up front. What this misses is that few
customers will buy pretty pictures of systems that they believe don't exist.
(The word 'believe' is important in the previous sentence.) Customers want to
see a prototype, and then after they see a prototype, they want the software
in production as soon as possible. It isn't surprising, then, how much
"production" code is really just band-aided prototype code. I've even been on
projects where key infrastructure components maintain the word "Prototype" in
the module name long after the code was facing real users.

The answer lies in mutual recognition. So many organizations have a wall
between sales/marketing and the techies. It's unfortunate that as soon as a
growing organization can have the luxury of separating salespeople from
techies, they do. In truth, the programmers need to understand the sales
cycle, and the techies need to understand the development cycle.

In the worst case, the two cycles produce dissonance. The best solution is to
have the two cycles complement one another. You want rapid prototyping,
customer involvement to maintain confidence, and refactoring. In my
experience, the Agile school of thought addresses these the best:

http://agilemanifesto.org/

> I'm not sure my own war stories for coping with difficult work environments
> and death marches are appropriate because they didn't happen at the same
> time. For the former I found more fulfilling side work within the
> corporation until I left, for the latter I bought into the hero culture
> working weekends and SO's b'day.

Software will always need heroes. I don't think anyone that has been at the
development game for a while hasn't done some hero time. But to climb the
chart of the Capability Maturity Model, you have to honor predictability:

http://members.aol.com/kaizensepg/cmm.htm

Otherwise, the organization is stuck at level 1, as many are --  "chaotic,
hero-driven, fire fighting, high-risk."

This is a case where the differences between software engineering and other
engineering disciplines is so striking. While other disciplines talk about
Total Quality Management and Six-Sigma, CMM patronizes the art of software
engineering by pointing out that our processes should be repeatable.

In explanation, Dr. Brooks' description of programming being like poetry and
us programmers working with "pure thought stuff" comes to mind. But not only
is software engineering much more abstract than a bridge, plane or automobile,
but it is also singular in the way that a new sewage treatment plant isn't.
Rather, the team of software engineers is presented with a problem such as
"there is sewage, and we need to treat it," and there is no context of
thousands of years of sewage treatment. Afterall, if the problem was easy, why
would the team of software engineers be assembled?

So by definition, I'm getting closer to the proof I desire: the higher levels
of CMM are usually only achieved by government, military and other large
institutional software shops with consistent funding. If you add the vagaries
of the sales cycle to the mix, it's hard to even reach "Repeatable" b/c the
problems are always singular and new. Thus, for the small shop the best shot
is to focus on the street wisdom of Agile Software Development.

> For dealing with difficult people, presented in Antipattern style:
> Toxic Coworkers: How to Deal with Dysfunctional People on the Job

I think this is where we need a new, less-cute, more dramatic Dilbert. Maybe
more like an action comic book with heroes and villains, ghouls and goblins...

I'm sure there is already one out there, but here are my thoughts... The
pointy-haired boss is too simple minded. What could spice up our plotlines
more than really troubled bosses wielding power they don't understand? This
will also provide a lack of order so that really dramatic conflict may
occur.... How about a mutant engineer-manager, cloaked in technical
objectivity one minute, exercising political cunning the next? You can have
the open sourcers... The high priests of the various techno-religions... the
 boy programmer that can do no wrong....
 the code cacklers... the vendors... the vindictive architect that must rid 
their domain of any that dare to disagree with them... the journeyman idea
merchant from a far away land that proffers radical new ideas and concepts to
the humble kingdom, and that will likely be strung up for sacrilege... the 
mute code monkeys that speak only through the perfection of their code.... 
the 
techno-politician that must shun all of those that can reveal their
 ignorance...

I'm thinking of a dramatic fictional world where techies clash brutally on
 the way to spectacular victories or flaming crashes. Lot's of KAZAAMS and
POWs.

Unfortunately, the teasers couldn't be much better than, "Read next week to
see if the build really broke." Or "will the open sourcers rally to prevent
vendor lock-in?" Or "will the promising young developer get lost in the vanity
of his own documentation?"