Monthly Archives: December 2013

Christmas is a Really Weird Holiday

Currier And Ives Christmas Village
The ancient Romans had a problem. A new cult arrived, bringing with it the most distasteful practices. The members all were atheists. They were also incestuous, and they had secret cannibalistic rituals.

The new guys? Some jerks called “Christians”. That’s right: they refused to believe in the Gods, they called each other “brother” and “sister” and greeted with a kiss, and rumor had it that they took part in some kind of ritual that involved eating the flesh and drinking the blood of others. Most folks thought they were killing babies.

New people are always bringing in new ideas and messing things up.

Take Christmas. As far as we know, some kind of holiday around this time has been celebrated forever. Go back ten thousand years, and you’ll find humans dancing around a fire around this day. They just didn’t call it Christmas. Nowadays the best scientific name for this day is the Winter Solstice. It marks the shortest day in the year, and it’s something that any culture that watches the sky would know and wonder about. Would the sun continue retreating? What could be done to bring Spring back? People built bonfires (along with large “yule” logs), used trees in ceremonies, had great gatherings, built huge edifices to properly revere the sun and help bring back much needed warmth to the land.

Then those new guys showed up with this fancy concept called “civilization” (a word which was only invented centuries later!). They wanted everybody to kind of standardize the holiday. Some of them settled on “Saturnalia” It was a pretty fun holiday. Slaves got to play the role of masters, and masters got to be slaves. There was drinking, families visited together, and everybody was thankful to spend time together. Geesh! Did we really need human sacrifices and all of that crazy superstitious stuff this time of year when we had the God Saturn and the proper celebration that should be given to him at this time?

But that didn’t last. And it was those atheist cannibal Christian types that ruined it.

At first, Christians refused to have anything to do with celebrating the birth of Jesus. Why should they? The entire religion was based on the death and resurrection of Jesus, not his birth. The first gospel written, Mark, makes no mention at all of Jesus’ birth. Later gospels went big on the story, though, with wise men, jealous kings, and all sorts of other great themes. But even then, early Christians had little interest in the beginning of the Jesus story. It was the last part that was the important part for them.

“It is only sinners like Pharaoh and Herod who make great rejoicings over the day on which they were born into this world,” said Origen, one of the most notable early church leaders.

People have a hard time believing this today, but early on it was the story of Christianity that was far more important than the historical detail or places. It wasn’t until the Middle Ages that visiting holy sites became much of a big deal. What would be the point of visiting a bunch of old places? Those things were trivial compared to the meaning of the story.

The Gospel of John helped to change that, but it took a long time. John was unlike any of the other three gospels (stories of Jesus’ life) in that it tried to join philosophy and religion together. Many scholars view John as being the product of an early Christian church with a heavy Greek influence. As science and the scientific method has progressed, people took this theme of philosophy and reasoning and started focusing on sourcing and facts. Christians are especially interesting in becoming more interested in “proving” that all these things have historical meaning and validation. Compare this to many other religions which to this day are not concerned with these matters. But I digress.

Because of this joining of philosophy and religion, or in spite of it, Christianity took off in a big way, eventually becoming the state religion of Rome, even though many still kept to the old ways too. Eventually this was a problem: fervent adherents wanted to know: why should we allow folks to keep celebrating this Saturnalia thing? People loved it, but it had nothing to do with Christianity. In fact, it was bad for the brand. It sowed confusion, it diluted the message, it hurt adoption.

So somebody came up with a great idea. “I know,” they said, “let’s keep Saturnalia and all that other stuff, but we’ll also have a celebration at this time for the birth of Jesus! We don’t do anything for that, and that way everybody can have a big party and at the same time be doing it the right way.” (Some scholars consider this the first great ancient marketing ploy)

So the organized, official Christian church used Microsoft’s embrace, extend, and extinguish strategy, but it still didn’t sit well with many of the troops. Why do we need to create some new holiday and do a bunch of pagan stuff? What kind of belief system is that? Indeed, most Christians refused to have anything to do with it. But it was great for converting the unwashed masses. For a long, long time, most Christians would have nothing to do with a mid-winter celebration in honor of Jesus’s birthday. In fact, in the New World, it was outlawed.

But slowly, over the centuries, most all of the Western World adopted this time of year as being appropriate to celebrate the birth of Jesus — if only in a muted way. Even though, of course, Jesus was not born at this time of year. It seems that when he was actually born had little to do with when his birthday should be.

But even all of that compromise wasn’t good enough.

First, people stayed upset about keeping the old traditions around. Geesh! Did we really need yule logs, trees, partying, and all that crazy superstitious stuff this time of year when we had Jesus and the proper celebration of his birth?

Second, for out on the lawn, there arose quite a clatter. Somehow in all of this arguing over when Jesus was born, or if we should actually care about it or do anything about it, one of the obscure Catholic saints, some guy called Saint Nicholas, took on a big role. He had a red coat, a flying miniature sleigh, delivered presents, and…

Wait, what? Where the heck did he come from? And what does he have to do with anything?

And that wasn’t all. The “Santa” story kept growing. He lived at the North Pole. His sleigh was powered by flying reindeer, one of which had a glowing nose.

Those Saturnalia folks have to be spinning in their graves. Would this crazy revisionist nonsense ever stop?

Of course, with modern education people are beginning to realize this silliness. And, just like people do, instead of consolidating something to celebrate, they are digging up all the old Pagan rituals and starting to celebrate them too. Of course, none of them have any idea what they’re doing, and it really doesn’t make a lot of sense, but, frankly, it makes as much sense as singing “Frosty the Snowman” while heading to a yule log ceremony following Christmas Eve church services (which you attended after watching the Macy’s parade, of course)

Meanwhile modern folks are asking if Christmas is a religious holiday after all. Geesh! Do we really need nativities, Christmas Eve Masses, Cantatas, Madigrals, and all that other crazy superstitious stuff this time of year when we have a wonderful inclusive secular holiday with this Santa guy and all this other non-religious stuff in it?

In programming we have a saying: the two hardest things to do are naming things and cache invalidation. What to call things and how long to keep ideas around before discarding them. Seems like programmers aren’t the only ones with this problem!

Our species has gone from animal spirits, to a Sun God, to the God Saturn, to the birthday of Jesus, to this big guy in a red suit, to this mish-mash of magic snowmen, glowing-nosed reindeer, and other nonsense. None of these have a dang thing to do with the other, but historically they all are part of the same thread stretching across the millennia from prehistoric darkness to today.

Like it or not, mankind is determined to have some kind of holiday around the time of the Winter Solstice, although what to call it, why to have it, and how to celebrate it seems up for grabs. Makes you wonder in ten thousand years, if some vestige of mankind still remains in the universe, what kinds of things we’ll be doing this time of year?

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Whatever Happened To Software Engineering?

map-clip-artI’ve been working some on my mailing list to help Agile teams do better and one of the recurring topics from readers has been how to fit “normal” software engineering principles into an Agile framework. How can you do database design, for instance, if every 2 weeks the database is actually being used?

Of course there’s an easy answer: we incrementally do things in Agile. So, for instance, you might use all those database design skills, but a little at a time, instead of all at once. The first sprint you sketch out the tables, maybe add a few fields. Second sprint you change up the tables some, add some more fields. Third sprint you’re working a bit with cardinality. And so on. The concept is that we do the same stuff, only a bit at a time instead of becoming a bottleneck.

This is a good enough answer, and it works for most stuff. But I think it’s also masking a conflict that many people have: software is supposed to be engineering, not just little dips and drabs of stuff added in here or there. To hear many YAGNI pundits and others, you don’t actually do anything until the last minute, and then only in support of the exact thing you’re working on. Most engineering disciplines, however, encourage you to solve the entire problem. If you’re building a bridge, architect the bridge first, dang it. If you’re going to the moon, you’d better have some technical work around the entire trip. You don’t just launch into orbit and figure it out from there. Building incrementally is fine. But there exists fields of inquiry where there’s a long sequential process of refinement over the entire problem domain — one in which you gain execution advantages by working the entire problem at once. We seem to either have tossed this fact away or are purposefully ignoring it.

I began noticing a problem. When we talk about these things, people shut down. I suspect many folks in software engineering, especially Agile coaching, don’t have an engineering background! This can lead to a severe disadvantage when dealing with certain areas:

  • Modeling I don’t see many teams sketch, much less model. That’s a shame, because visual information is a much more effective way to discuss technical matters. Add in a bit of formal training, say 30 minutes, and teams can sketch in UML. Then you can link diagrams. There’s something to be said for lightly sketching problems on the whiteboard. Take a picture if you want to keep it. Start using a modeling tool if you realize that you’re having a group discussion around highly technical stuff. You can sketch, you can use UML, you can use a modeling tool, all without having to become a waterfall BDUF project. Really, you can. It’s the only way to go for complex projects.

  • Process Analysis Does anybody remember structured process analysis? Not to see most teams. The way most people teach Scrum and Agile is that a list of stuff appears — I guess from the sky, brought down by a dove to the Product Owner. The team only works on the stuff in front of it. Don’t spend a minute thinking about the big picture! After all, your project could end at any point in time, and you don’t want to spend one minute on things that you’ll never need.

    Of course, there ARE projects that could end at any moment, but for most of us, we’re brought on to address some kind of system: a website, a business problem, an internal need, and so on. The team, and project, has some cohesion. You’re going to be here in six months, and you’re going to be working on the same thing. For those kinds of projects, spending some time doing process analysis is a no-brainer. You get back much more than you put in. I’m not talking about anything waterfall-like. I’m simply talking about building a process model, over time, of who does what with the system and why. This can help you cut to the chase and decide which stories should be prioritized first. It can help you define and have a common understanding of your stories. It can help the Product Owner make economic decisions about the backlog, and it can help the team interject creativity into the solution, instead of just being a bunch of order-takers. Great stuff for couple hours or so each sprint.

  • Lean Startup Another one of those end-to-end, outside-the-team areas where the team and the Product Owner need to work. What hypotheses is this work supposed to be testing? What are the revenue streams? How are we addressing the gap between market and PO? In a startup world, all these things are critical — and there’s a sequential engineering-type endeavor that can take you from point A to point B. It’s a mistake not to do it.

When we teach things like good architecture or proper database design, many times we view the developer as the center of the universe and the engineering practice as something that’s completed in toto before any other work can occur. This has caused tremendous pushback from Agile teams, rightly so, because it creates handoffs, bottnecks, and unecessary documentation. But are we overreacting the other way? Isn’t there a place for long-format, sequential, detail-oriented work, even in Agile teams in complex domains? Especially in Agile teams dealing in complex domains?

Each of these has a few areas in common: 1) they’re about more than the work directly in font of the team, 2) they’re about having the experts, the team, assist the organization in its work, 3) they’re sequential, 4) they build on themselves as work gets done, 5) they’re not the work itself, and 6) they end up discovering things for the PO and the organization that wouldn’t be discovered otherwise. Because of these attributes, they tend to “fall between the cracks” when teams adopt Agile practices. They are traditionally part of what people employ engineers to do.

How about you? Are there engineering processes you miss seeing in your Agile teams? What are you doing to make up for it?

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.