Brainstorming is silly

By definition, brainstorming([1]) originated as a technique to create random noise idea aggregates.

The commercial folk wanted to create novelty - whatever novelty. The purpose of the result was not to be deep or insightful, merely to create moments diversion that could be spun into the marketing narrative.

Today, you can achieve the same effect by using oh-so-many random generators available in almost any context.

If you have a specific task in mind you would like the team to collaborate on, brainstorming is probably not a skillful technique to employ.

I would suggest that an online chat with a specific agenda, that is shared with all members, is a far superior facilitator for team collaboration and idea development.

If you want to leverage intuition, it needs time for individuals' brains to muddle over the thing. It needs GOALS, and it needs TIME. And then it needs a platform for sharing. A chat-based communication medium, combined with a collaboration platform such as Office365 or Google's offering is wonderful for this.

A high functioning team may engage in activity that to an outside observer looks exactly like brainstorming. People standing in a room, post-its are filling every vertical surface and the team is in animated discussion over some fine point. This is not brainstorming, this is regular team-based activity. It did not start with the explicit call to arms "Brainstorming time! Let our post-its combine!" but rather by the simple need of planning things and getting the Post-its out was probably the most natural medium of communication.

Brainstorming and regular team-based design work in a room with post-its have the same relationship as a plane landing on a field and a person guiding the plane to its parking spot with guidance flags. The guy with the flags does not call the airplane. The airplane comes anyway. The guy with the flags just makes this simpler. You can't call a plane by just waving the flag. Similarly, you should not expect novel insights by just locking people in a room with Post-Its and pens. This is an obvious reference to cargo cult methodologies ([2]) in general that confuse cause, effect, and trivial details into a wonderfully incoherent mishmash of silliness.

[1] https://en.wikipedia.org/wiki/Brainstorming
[2] https://en.wikipedia.org/wiki/Cargo_cult

There are no silver bullets

A silvery bullet on a concrete background, surrounded with yellow hue. Inscribed with the text "There are no silver bullets", referring to the classic book "The Mythical Man Month" by Fred Brooks and the constant futile search for technological solutions for deeply human problems in the software industry.

If you like this, you can purhcase a high resolution digital copy suitable for printing in A3 size or similar: https://gumroad.com/l/iNgvk

Should you give Software Engineers arbitrary deadlines "Just to keep everyone honest'?

This is a response I recently posted to a dicussion forum. I'm copying it here since I find I reached a fun tone that I personally enjoy.

The setup - "Should you ever give software engineers fixed deadlines?"

Statement:

"but you have to admit that without a date developers will just noodle around forever."

Response:

Speaking for myself as a software engineer I have only seldom fixed dates and deliver constantly. My main goal is to deliver value to the party I work for and my end users.

True artists ship.

On the other hand, I do stall occasionally. It's because I don't understand something, and rather than just ship some random junk I try to make my junk do the right thing.

To an outside observer this carefull design - engineering if you will - is quite indistinguishable from noodling.

If you put an arbitrary date for me then you will just get bad code and that is a bad deal for everyone.

There are times when the date *is* fixed. Then you haul ass and raze mountains to ship, no matter how ugly the result.

If the date is constantly set to some random date I have no idea should I dial quality down and increase velocity or vice versa. Therefore a constant fixed date will just get worse quality, even if there was no good reason to hurry.

I think the main concern is how to have enough transparency so that everyone is honest and accountable.

You don't need imaginary dates for that. Just have people report at fixed cadence what they've done. Good people remember they need to explain what they've done and dont wander off into the wilderness for no good reason. This is sufficient to keep everyone on the right track *in almost any environment*.

Now you say - "Aha! But what about the occasional person who is incapable of doing their job! How do we point him out!" - to which I answer: If you need to design your development process to safeguard against botched hiring since they seem to do it constantly you really need to fix your hiring. Good people will detect a rotten egg eventually and there should be ways to deal with this *outside* of regular project cadence. If you try to micromanage great engineers and programmers you are just wasting talent and eventually everyone will just move on and all you have left are the rotten eggs.

Outsourcing is the death of innovation

The only known way to create new things in technology is to hire good people and let them do "the right thing". The definition is vague. That's because no one has effectively succeeded in taking it any further. It's about people, their capability, motivation and indicated proper conduct at the workplace.

When you outsource things, you are effectively taking the chance away from your organization to innovate in this space.

Outsource only commoditized things.