Estimate. Or do not. There is no try...

I talked with a technical lead last night and it was fascinating.

He said, "You're suggestions for estimation don't work."  He was referring to the several posts I've made on this blog and in emails about estimating.

He continued, "I asked one of my guys for an estimate, he said 2 days, I said 7 days, it took 6 days.  This happens for all our estimates."

"Why do you continue to ask him for estimates?"

Service Oriented and Agile...

I think that when Agile came along there were many people in software that didn't understand dependency management and software engineering.  I believe this encouraged architecture and design to be thrown out "with the Agile bath water."

Why user stories and the thin slice are a lie...

TLDR: User Stories are integration points, not slices.

Provocative title, yes?  Well, give me a moment to explain and I think you'll understand.

In the lore of Agile there is the notion of the "thin slice."  The idea is that you build just what's needed to implement the current user story. You "slice through" each level of the solution architecture and implement the user story.

I've had real problems "thinly slicing" the solution architecture along user story boundaries. The primary problem is that the user story is focused on functionality delivered to the user, but there is a lot more than providing user-visible functionality needed to complete a modern project.

Why you're (probably) not building your own web tools...

I think I've spotted a trend.  I've worked with a lot of brilliant developers over the years, but only a few create their own tools ( Jeremy Ruppel, Don Robins ).

Others that I thought would, don't seem to.  (I'm looking at you AKQA Boys).  If they do, they don't mention them.

The trend I've noticed is expressed by Adam Savage of Mythbusters Fame.  He's a big promoter of making and was at Maker Fair saying so.  He even wrote his own 10 commandments of making:

https://www.youtube.com/watch?v=IclNcfEqYaA

The trend I think I've noticed is that if you got into software because you were smart and thought it sounded like a degree for a smart person, or you were at the head of your class in high school ( you know, head of the idiots that were back in HS ), then there is a very high chance you won't create your own software.

On the other hand, if you got into software because you were a maker, an electronics tinkerer, or because you were trying to solve a problem, realized you were good at this and then got a job - even if you went back to school and got a degree - then there is a very high chance you create your own software.

Disaster avoidance: Step one, check for false beliefs...

In early 2012 I was scrum-master on the largest project my office had ever attempted and it was to be a disaster of epic proportions. I tried to prevent the disaster but couldn't. Now, a year and half later, I think I have figured out why. The bad news is that almost all organizations and teams face some variation of this tale. The good new is this story just might help you prevent your own disaster.

The disaster that is declared a success...

Have you ever been a part of this weird - yet very common - dynamic?  The successful disaster?

Are you models skillful...

If you get a chance, you should consider watching this TED Talk

I'm not asking you to watch it to increase your belief in the hoax that is global climate change, but rather to hear his argument about the models themselves.

He takes the position of asking if the models are "skillful."  In other words, do the models offer us more than if we didn't have the models at all.